On Mon, Feb 3, 2014 at 10:58 PM, Jeremy Linton <jlinton@xxxxxxxxxxxxx> wrote: > On 2/3/2014 2:51 PM, Kay Sievers wrote: >> This is not simple and not going to happen. Sibling devices in /sys cannot >> have a relationship in udev, there are only parent/child dependencies. > > Ok.. so if we can't ignore all the "spare" device nodes in a given /sys entry > for a given device. Why open the device to scan it? > > I've often wondered why the serial number isn't part of the data in /sys > along with the manufacture/model. The last tape drive I saw that failed to > respond to inquiry page 0x80 was over a decade ago (probably manufactured in > the early 90s). So enabling it just for tape is pretty safe. > > > Matching Manufacturer/model/serial is going to be better than anything your > going to get out of 0x83 anyway. That data is guaranteed to be there, but its > also guaranteed to be unreliable (every device, and every port has a slightly > different set of descriptors they choose to support). > > Plus, your not going to have issues accidentally rewinding a device, or > resetting a tape density, or accidentally turning compression off if you don't > open the device. Well, the predictable symlink for tapes stuff is all pretty old, and got through quite a few changes over the years. Not sure how much the /dev/tape/by-*/ links are really used in the field, and what people really expect here. (Mis-)using one of the various open() flags which do not make sense for SG_IO or tapes, which would prevent any state changes still sounds like the most convincing option to me. In the end it's always the nicer interface if the device node itself can be used to identify the device, instead of jumping through /sys or adding more proping caches to the kernel. >> Hannes, can't you just drop the weird auto-rewinding device matches from >> the persistent rules, is that really useful today? > > The relationship between the st and nst devices is leveraged by a large > number of backup applications in the field. If you change it, its likely lots > of breakage will ensue. Sure, but do they really expect the additional symlinks udev creates? We are not talking about the primary device nodes, only about the additional /dev/tape/by-*/ links. Kay -- 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
