On Fri, 2011-03-04 at 09:32 -0500, David Zeuthen wrote: > 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. This really doesn't sound like such a good idea. The smart commands have to be ATA_16/12 encapsulated. There's already a pile of bugs saying that this fails (including causing crashes) because various internal firmwares don't process the encapsulation correctly. The LSI firmware, is the majority culprit, by the way. > 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. James -- 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
