-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/03/2014 03:50 PM, Jeremy Linton wrote: > On 2/2/2014 5:42 AM, Hannes Reinecke wrote: >> This is due to the strictly sequential design udev has. >> Essentially udev spawns a worker for every device which gets >> created (= udev receives a uevent for). > The part I fail to see in this explanation is why the > nst/st/st*a/st*m/etc handles are being treated as separate > devices. They aren't. They are all the same physical tape > device, so why are the nst devices being handled separately > from the st ones? > That's due to udev. Udev is getting events for each device it should create a device node for. So for 'st' it'll get a series of events for 'stX', and another series of events for 'nstX'. Udev will treat each of these events separately, with distinct worker programs handling them. Each of those workers run fully asynchronous and cannot access information from other workers. Udev cannot and should not make assumptions about any correlations between events; if you need this then you have to explicitly gate events via the 'collect' mechanism. But even then you can only access information from the currently running process/event; you cannot modify information from prior events.
So when trying to generate unique IDs for tape devices you either have to a) modify the program generating the Unique ID to redirect the call to a different device node or b) to modify the driver to not rewind the tape We tried approach a) when using the scsi_id program. But as this program is rather old and doesn't have a maintainer I'm working on using 'sg_inq' as a replacement. And these kind of hacks really do not belong in a generic program. (It would involve create a temporary device node, call SG_IO on that, and remove the temporary device node again). So now we're shooting for b). Unless you have a better idea ... Cheers, Hannes - -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +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) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS77BsAAoJEGz4yi9OyKjPQz8P/1cY+k9KtEezXC2ovuzJmy9T BjQaoxcTgHbaXykFyEoJeiNQ09XrjAl7IlVOOF9jX3XqC4kYQiBZCThUnC8O3D69 vaZrA6+VR9AoTXbfNzBUdHzEKWTlz5X2ThLzrLPogXS6v5hiw0iBcLq5mvlJxlkc DBHJrV+ujlKOM/JibNwUNldeYAFnrrzCCH50arJ/Eqa6BcLZ2uXTksACqIVybUoI nW1yfVzJdsxI5YwPp0N5bnuAPIg3N7zBTcFCVYqTHUiAmrS4HYkHRrC501yuopCA PS9Gv1KznctEIGudoP5S0Lwn+g/aVSuzOTpo3uUWAa1BNyyvRMRUSzSIUfm2WdAj +o1mswhhX6NZMM9rFrM35dbiky2Nv/pvc2zcD4pvizsLiHkoQER7GQ9FCaBNXP7d eK0OF2jJeEPV6LSC97wxH27Vybv/c89wp0HGDaJc+kd8+WZFIvkLbvY7K3BSA2ut YvuebI59veIYNZEJVEdAGYQ3IEUG8uukbdpqf3Kdr17PQEms/gTW+xYWPo1+hBR7 V58ojgghBxPdVwGRyiSgKgjY/vHLFunm9H83LDrHKdQsKs8JGiTCflPhJEMwwsDo mhlmd5Ihw20Cyh46sd3Uu1onH0L5Rg0hfDqT913ShUFYi5Y+XvtHEezYn73OxYDr JoUo9HYfT843MabEympC =c45s -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
