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 ...
