Messages in this thread | | | Subject | Re: [ANNOUNCE] v4 sg driver: ready for testing | From | Douglas Gilbert <> | Date | Wed, 16 Jan 2019 19:56:23 -0500 |
| |
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 ... >> >
| |