On Fri, 2011-03-04 at 09:41 -0600, James Bottomley wrote:
> > 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).
>
> OK, so why not simply an event on BSG device creation then? To make
> what you want to do work, it sounds like we should be moving BSG binding
> farther back in the configure sequence (to the same place where we'd be
> binding an ordinary ULD). It also perhaps sounds like we don't need any
> events on the sdev. The only reason we might find them useful is if we
> were going to do configuration from user space (which was a proposal
> once upon a time). The sdev was never designed to be any sort of thing
> the user saw (well, except as an identifying label). That's why you
> need to bind a driver (including bsg) to speak to it.
Not entirely sure what you exactly are proposing here but note that the
root problem is that the block device and bsg device are siblings... the
only way this can work without races in user space is to have their
common ancestor do the work (e.g. run /lib/udev/scsi_id + friends) on
the 'add' uevent, not on some 'change' uevent later... there is just no
way it will work otherwise.
If we didn't care about backward compat, maybe it could look like this
0:0:0:0
+-- dev <-- this is dev file for the bsg device
|
+-- block
| +-- sdb
| | +-- dev <-- this is the dev file for the block device
so we get the bsg device as the first uevent and the block device with
the other one. With this setup we'd run /lib/udev/scsi_id + friends on
the bsg device node and then we'd import it for the block device node
and everything would be good.
That said, I don't think we can make such a change as it would probably
break some parts of user space...
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
