Re: [PATCH] st: Do not rewind for SG_IO

[Douglas Gilbert <dgilbert@interlog.com>]

On 14-02-03 10:08 AM, Jeremy Linton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2/3/2014 9:06 AM, Hannes Reinecke wrote:
>
>> That's due to udev. Udev is getting events for each device it should create
>> a device node for. So for 'st' it'll get a series of events for 'stX', and
>> another series of events for 'nstX'. Udev will treat each of these events
>> separately, with distinct worker programs handling them. Each of those
>> workers run fully asynchronous and cannot access information from other
>> workers.
>
> 	So whats wrong with the simple solution? You throw the ones for st away, and
> create the st handles from the nst worker.

Doesn't seem to be any good solutions to this
problem. If you can't discovery something without
modifying its state, then what? For udev and/or
sg_inq to know about the special relationship
between st<i> nodes and nst<i> nodes seems
unreasonable IMO.

The cleanest way I can think of is for the st driver to
show this relationship via sysfs. But then why should
udev going mining for that relationship? A sysfs flag
from the st driver indicating a node is "undiscoverable"
might be a start.

A possible hack inside the st driver is to notice that
only the SG_IO ioctl is called on a file handle
between st_open(/dev/st*, O_RDONLY|O_NONBLOCK) and
st_release() then not auto-rewind it.

BTW Recent versions of sg_inq in Linux use
open(<dev>, O_RDONLY|O_NONBLOCK) unless 'sg_inq --block=1'
is given in which case open(<dev>, O_RDONLY) is used.


I just noticed that when scsi_debug makes a tape device,
the st driver silently ignores it, probably because
scsi_debug doesn't support a SSC command that st expects it
to respond to. IMO the st driver should make some noise if
it ever ignores a SCSI device with a PDT of 1 (i.e. a tape).

For example:
# lsscsi -g
[0:0:0:0]    disk    ATA      INTEL SSDSC2CW12 400i  /dev/sda   /dev/sg0
[8:0:0:0]    tape    Linux    scsi_debug       0004  -          /dev/sg1

with the st module loaded and no indication in dmesg.

Doug Gilbert