Re: Problem in udev with %e device numbering

[Kay Sievers <kay.sievers@vrfy.org>]

On Sun, 2005-01-30 at 11:39 +0100, Michael Gutmann wrote:
> On Sat, 2005-01-29 at 20:53 You wrote:
> > On Sat, 2005-01-29 at 18:53 +0100, Michael Gutmann wrote:
> <...>
> > > card is put into the card reader. Unfortunately they are only found if
> > > something tries to use the card, f.e. fdisk.
> >
> > If you don't use anything that polls the device for a media change,
> > which is what all major desktop installation do today, you don't get
> > these nodes, yes.
> 
> Sorry, didn't want to blame udev for doing this. I was rather 
> disappointed, that the card reader didn't announce changes itself ;-)

I've never seen any USB storage device that can do this. Only one, that
causes a whole USB device diconnect on media removal. :)

> > > So I have to use NAME(all_partitions}. No problem so far, but I want to
> > > use symbolic names instead of sd?. But if I use SYMLINK="cardreader%e"
> > > f.e. there are only links to sd[abcd] and not to the partitions.
> > > The only way I see is using NAME{all_partitions}="card%e".
> >
> > There is no sane way to use the %e key in cases you get concurrent
> > events asking for enumeration of the same name. It's a too simple hack
> > and there is no way with the current udev model to get this fixed inside
> > of udev.
> 
> Oh shit. I get your point:
> 
> Jan 30 11:17:47 localhost kernel: usb-storage: device found at 2
> Jan 30 11:17:48 localhost kernel: usb-storage: waiting for device to settle before scanning
> Jan 30 11:17:48 localhost usb.agent[5358]:      usb-storage: loaded successfully
> Jan 30 11:17:52 localhost kernel:   Vendor: Generic   Model: Flash R/W         Rev: 2002
> Jan 30 11:17:52 localhost kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
> Jan 30 11:17:52 localhost kernel: Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0
> Jan 30 11:17:52 localhost kernel:   Vendor: Generic   Model: Flash R/W         Rev: 2002
> Jan 30 11:17:52 localhost kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
> Jan 30 11:17:52 localhost kernel: Attached scsi removable disk sdb at scsi0, channel 0, id 0, lun 1
> Jan 30 11:17:53 localhost udev[5456]: configured rule in '/etc/udev/rules.d/10_micha.rules' at line 3 applied, 'sda' becomes 'card%e'
> Jan 30 11:17:53 localhost udev[5481]: configured rule in '/etc/udev/rules.d/10_micha.rules' at line 3 applied, 'sdb' becomes 'card%e'
> Jan 30 11:17:53 localhost kernel:   Vendor: Generic   Model: Flash R/W         Rev: 2002
> Jan 30 11:17:53 localhost kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
> Jan 30 11:17:53 localhost kernel: Attached scsi removable disk sdc at scsi0, channel 0, id 0, lun 2
> Jan 30 11:17:53 localhost udev[5499]: configured rule in '/etc/udev/rules.d/10_micha.rules' at line 3 applied, 'sdc' becomes 'card%e'
> Jan 30 11:17:53 localhost kernel:   Vendor: Generic   Model: Flash R/W         Rev: 2002
> Jan 30 11:17:53 localhost kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
> Jan 30 11:17:53 localhost udev[5499]: creating device node '/dev/card0'
> Jan 30 11:17:53 localhost udev[5499]: creating device partition nodes '/dev/card0[1-15]'
> Jan 30 11:17:53 localhost udev[5481]: creating device node '/dev/card0'
> Jan 30 11:17:53 localhost udev[5481]: creating device partition nodes '/dev/card0[1-15]'
> Jan 30 11:17:53 localhost udev[5456]: creating device node '/dev/card0'
> Jan 30 11:17:53 localhost udev[5456]: creating device partition nodes '/dev/card0[1-15]'
> Jan 30 11:17:53 localhost kernel: Attached scsi removable disk sdd at scsi0, channel 0, id 0, lun 3
> Jan 30 11:17:53 localhost kernel: usb-storage: device scan complete
> Jan 30 11:17:53 localhost udev[5522]: configured rule in '/etc/udev/rules.d/10_micha.rules' at line 3 applied, 'sdd' becomes 'card%e'
> Jan 30 11:17:53 localhost udev[5522]: creating device node '/dev/card1'
> Jan 30 11:17:53 localhost udev[5522]: creating device partition nodes '/dev/card1[1-15]'
> 
> But here I get into trouble: with kernel 2.6.10 device numbering is 
> serialized dependent on the physical device (as I understood the 
> discussion last december) As you can see, the different parts of the
> card reader are identified as luns. Isn't it possible to identify the
> physical device behind that luns and serialize the numbering for it?

Maybe we could, but it doesn't really address the fundamental flaw.
What if I connect more than one of these readers at the same time? The
enumeration numbers will still get mixed up.

> > The only sane solution, I can imagine would be an external program, that
> > does the enumeration and returns the value to udev. This external
> > program would need to maintain its own database in a dotfile in /dev and
> > must use a file lock to serialize concurrent processes asking for the
> > value. This topic was already discussed on this list, you may look at
> > the archives...
> 
> Argh, this misses the elegance I marvel at udev.

Yes, that's not nice, but I really don't know how we could do a nice
enumeration over multiple devices/subsystems. The only thing, which can
be solved(using file locks) is that the enumeration counter does not
hand out the same number multiple times(as it can happen today).

The only sane solution is to use custom rules for every device and match
against individual attributes to create individual names for every
device, or to encode the topological position into the device name.

To create a single enumerated device name with sane sequences for
multiple devices seems like an unsolvable problem.

Kay



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel