Hey,
On Thu, 2011-03-03 at 11:56 -0600, James Bottomley wrote:
> On Wed, 2011-03-02 at 14:02 -0500, David Zeuthen wrote:
> > From: David Zeuthen <davidz@xxxxxxxxxx>
> >
> > udev should be able to examine a scsi device (e.g. retrieving VPD like
> > the make/model and serial number) before announcing it to the rest of
> > user space. Currently this is not possible because the scsi device has
> > no device node of its own. Instead, user space will have to use either
> > the bsg device or sg device but these are not available at uevent add
> > time since both are children of the scsi device
>
> This premise sounds a bit wrong. SCSI devices go through several
> distinct phases: create, add and then configure. We send the initial
> probe before the add phase, but no user should really poke at the device
> before the configure phase because that's where we set the
> characteristics and other stuff. The signal to udev that the configure
> phase is over is when the ULD binding completes. That's when the device
> is running and it's safe to poke at. It also means it's been identified
> internally and you'll know whether it's a disk, a tape or whatever.
>
> So you should see two distinct events: an ADD for the sdev, meaning we
> think there's something there, but at this point there's no real device
> for a user to see followed by the add for whatever the ULD major device
> binding is ... at that point, we guarantee the device is up, its bsg
> queue is registered, there's actually a user block or character device
> corresponding to it and we've finished configuring it.
>
> What exactly are you trying to do here? It's really not that safe to be
> running user level poking in parallel with the configuration scanning
> we'll be doing as the ULD binds.
So there are basically two things I'd like to achieve here
1. Have bsg-symlinks for SCSI devices like this
/dev/bsg/by-id/scsi-0x05-SEAGATE-ST3300657SS-3SJ1S7K600009051M0CE
/dev/bsg/by-id/scsi-0x0d-PROMISE-2U-SAS-12-D2-BP-35000155350e0133e
(e.g. scsi-<type>-<vendor>-<model>-<t83-serial>)
2. Some RAID HBAs / drivers (I've seen this with a LSI1068 using the
mptsas driver) expose the disks that are part of a HW RAID as
scsi device but there are no block devices for them. This allows
user space to send SMART commands (using the bsg node) and nag the
user if a disk is failing.
Note that we can already do all this today but since the sysfs layout
looks like this
0:0:0:0
|-- block
â +-- sdb
| | ...
|
|-- bsg
| +-- 0:0:0:0
| | ...
This setup is rather unfortunate because the bsg device and block device
are siblings and, thus, cannot share information with each other. This
is because only children can import information from their parents -
anything else is prone to races.
Now, since we currently run scsi_id + friends on the block device it
would mean running these tools _again_ on the bsg device. Which,
honestly is a waste. So the idea was simply to always run it on the scsi
device (using the bsg node) and simply just import the data to the block
device and bsg devices (both are children of the scsi device).
David
--
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
