lkml.org 
[lkml]   [2019]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [ANNOUNCE] v4 sg driver: ready for testing
From
Date
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 ...
>>
>

\
 
 \ /
  Last update: 2019-01-17 01:57    [W:0.050 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site