On Fri, 2011-03-04 at 11:50 -0500, David Zeuthen wrote: > 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... Right, but that's a consequence of the fact that we allow multiple upper layer driver bindings. What I'm telling you is that you can't trigger off the ADD event on the sdev because the device isn't ready at that point. What you need to do is trigger off the event for binding the ULD(s) ... but I'm also warning that the multiple binding nature of ULDs always makes this racy. If you shift to using the bsg device, we'll have to make sure it isn't advertised until the system is ready to receive packets down it ... and I suspect we might be creating it a bit early in the current setup, simply because no-one has used it like this before. You have a guarantee that there will always be a bsg device ... so if you want to use that for a probe, fine, cache the results on it. I don't think we can ever guarantee that the other ULD will (or won't) be there at the same time, so surely you can make udev on the other device wait until the bsg based probe completes? James > 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 -- 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
