On 02/06/2014 03:38 PM, James Bottomley wrote: > On Thu, 2014-02-06 at 08:50 -0500, Martin K. Petersen wrote: >>>>>>> "Hannes" == Hannes Reinecke <hare@xxxxxxx> writes: >> >>>> My patch provides both the original VPD 0x83 and 0x80 bits as well as >>>> a handle identical to /sbin/scsi_id. >>>> >> Hannes> Bah, don't do that. That should better be handled by udev >> Hannes> rules. I've got a set of patches moving from scsi_id to sg_inq, >> Hannes> which can be easily adapted to using sysfs directly. >> >> I just want to get out of the "userland sending random SCSI commands" >> business. That is a world of pain right now. > > Well, in the words of Bill Clinton "I feel your pain". However, I need > to know we won't pick up that same whole world of pain in the kernel. > Remember it's not just SCSI devices, it's also ATA devices and > potentially other block devices ... then there's blkid and all the weird > things it does. Then there's transport identifiers for multi-path > reservations and so on. > blkid is actually not so bad, _if_ it would distinguish between 'metadata not found' and 'I/O error during metadata read'. I made a patch which hopefully should find it's way upstream. And blkid just issues plain READ commands, so _this_ behaviour won't change ... > Convince me this path won't have us shifting a whole bunch of weird from > user space to the kernel without any reduction in the weird factor. > Remember the point is not what can we do for all the nicely behaved > SCSI-3 devices, it's what do we do for everything. > Well, first and foremost the patch should be limited to SCSI-3 (and later devices). So we'd be insulated from the most obvious crap. So that leaves only devices which claim to be SCSI-3 or something, but still keel over when asked for VPD pages. However, this type of devices will fail already, as 'sd.c' is already asking for all sorts of VPD pages. Which leaves only non-Disk devices, but those tend to have a better SCSI implementation as you can't make quick bucks with, say, as SCSI Enclosure device. But the prime motivator behind this patch is that we can be reasonably sure the device will answer at all. When retrieving the EVPD pages from userspace you always have the problem that the device might have gone away or being unresponsive by the time you get around sending the SG_IO call. So you always have these stuck user-space processes asking for information which _had_ been present at one point. In particular udev is prone for this; anyone who ever came across the message udevd[]: worker unexpectedly returned with status 0x0100 knows what I'm talking about ... And the more udev events for a device you get, the higher the likelyhood for this to happen is. Plus I could re-use this information for my scsi_dh_alua patchset, and for xcopy and friends we'll be needing it, too. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
