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
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
