Re: [ANNOUNCE] v4 sg driver: ready for testing

[Douglas Gilbert]

There is an update to the SCSI Generic (sg) v4 driver adding synchronous
and asynchronous bidi command support. Plus lots of fixes and some minor
improvements. See:
    http://sg.danny.cz/sg/sg_v40.html

The kernel code is split in two in the tarball below, one targeting
lk 5.0 and the other targeting lk 4.20 and earlier ***. Each section
contains the 3 files that represent the sg v4 driver plus a meandering
17 part patchset. Those patchsets reflect the driver's rewrite rather
than a logical progression.
    http://sg.danny.cz/sg/p/sgv4_20190116.tgz

Plus there are updated testing utilities in sg3_utils-1.45 (beta,
revision 807) at the top of this page:
   http://sg.danny.cz/sg/index.html

Doug Gilbert


*** the reason for the split is the tree wide change to the access_ok()
    function.


On 2018-12-25 2:39 a.m., Douglas Gilbert wrote:
> There is an update to the sg v4 driver with some error fixes, SIGIO and
> RT signals work plus single READ, multiple WRITE sharing support. See:
>  ÂÂÂ http://sg.danny.cz/sg/sg_v40.html
>
> with testing utilities in sg3_utils-1.45 (beta, revision 802) on the main
> page:
>  ÂÂÂ http://sg.danny.cz/sg/index.html
>
> Doug Gilbert
>
>
> On 2018-12-18 6:41 p.m., Douglas Gilbert wrote:
> > After an underwhelming response to my intermediate level patchsets to
> > modernize the sg driver in October this year (see "[PATCH 0/8] sg: major
> > cleanup, remove max_queue limit" followed by v2 and v3 between 20181019
> > and 20181028), I decided to move ahead and add the functionality proposed
> > for the version 4 sg driver. That means accepting interface objects of
> > type 'struct sg_io_v4' (as found in include/uapi/linux/bsg) plus two new
> > ioctls: SG_IOSUBMIT and SG_IORECEIVE as proposed by Linus Torvalds to
> > replace the unloved write(2)/read(2) asynchronous interface ****. There
> > is a new feature called "sharing" explained in the web page (see below).
> >
> > Yes, there is a patchset available (14 part and growing) but even without
> > explanatory comments at the top of each patch, that patchset is 4 times
> > larger than the v4 sg driver (i.e. the finished product) and over 6
> > times larger than the original v3 sg driver! Part of the reason for
> > the patchset size is the multiple backtracks and rewrites associated
> > with a real development process. The cleanest patchset would have 3
> > parts:
> > ÂÂ 1) split the current include/scsi/sg.h into the end product headers:
> > ÂÂÂÂÂ include/uapi/scsi/sg.h and include/scsi/sg.h
> > ÂÂ 2) delete drivers/scsi/sg.c
> > ÂÂ 3) add the v4 drivers/scsi/sg.c
> >
> > After part 2) you could build a kernel and I can guarantee that no-one
> > will be able to find any sg driver bugs but some users might get upset
> > (but not the Linux security folks).
> >
> > So there is a working v4 sg driver discussed here, with a download:
> > ÂÂÂÂ http://sg.danny.cz/sg/sg_v40.html
> >
> > I will keep that page up to date while the driver is in this phase.
> > There is a sg3_utils beta of 1.45 (revision 799) package in the News
> > section at the top of the main page:
> > ÂÂÂÂ http://sg.danny.cz/sg/index.html
> >
> > That sg3_utils beta package will use the v4 sg interface via sg devices
> > if the v4 driver is detected. There are also three test utilities in
> > the 'testing' directory designed to exercise the v4 extensions.
> >
> > The degree of backward compatibility with the v3 driver should be high
> > but there are limits to backward compatibility. As an example, it is
> > possible that there are user apps that depend on hitting the 16
> > outstanding command limit (per fd) in the v3 driver and go "wild"
> > when v4 removes that ceiling. If so, a "high_v3_compat" driver option
> > could be added to put that ceiling back.
> >
> > The only way to find out is for folks to try and if there is a failure,
> > contact me, or send mail to this list. Code reviews welcome as well.
> >
> > Doug Gilbert
> >
> >
> > **** I felt this was a better use of my time than trying to invent a new
> > ÂÂÂÂÂ debug/trace mechanism for the whole SCSI subsystem. That is what
> > ÂÂÂÂÂ _SCSI_ system maintainers are for, I'll stick to the sg driver (and
> > ÂÂÂÂÂ scsi_debug). Add user space tools and there is more than enough work
> > ÂÂÂÂÂ there ...