Re: new version of udev has different cd/dvd devices

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

On Fri, Dec 30, 2005 at 07:47:38PM +0000, Darren Salt wrote:
> I demand that Kay Sievers may or may not have written...
> 
> > On Fri, Dec 30, 2005 at 06:16:54PM +0000, Darren Salt wrote:
> >> I demand that Greg KH may or may not have written...
> 
> >>> On Thu, Dec 29, 2005 at 12:29:36AM +0100, Kay Sievers wrote:
> >> [snip; creating static rules on-the-fly]
> >>>> Distros could also have a "default" rule, which catches unconfigured
> >>>> devices and automatically creates a rule for them to keep the name
> >>>> stable across reboots.
> 
> >>> Or we can just stick with the rules we have today that use %e just fine,
> >>> as it emulates exactly what a static /dev would have done, and no one is
> >>> complaining about it :)
> 
> >> Well, other than that it's become broken along with various other things
> >> (in my case, ALSA sound device numbering; fortunately, the machine in
> >> question has just the one external network interface) due to a change
> >> elsewhere. And we all know what that change is, don't we :-)
> 
> >> A switch which says "process events in series" or "process events which
> >> match this rule in series" (hmm, groups of rules?) would do for my
> >> purposes. Faster booting's all well and good, but I think that the cost is
> >> just a little bit too high in this case.
> 
> > Forget "order" of devices on a system where everything can come and go at
> > any time.
> 
> Hmm. Drivers built into the kernel, devices require shutdown for
> replacement... well, that's the case for my DVD drives.

Good luck if libata starts to handle parallel IDE  devices too. And _everthing_,
all block devices, becomes sd*, sr*, like recent SATA boxes alreay do.
Latest then, you better start to think about this.

> > The time can we configure a system once at installation is long over.
> 
> I don't recall making any mention of one-time configuration.

Sure, you did. %e is always "one-time" and relies on hardware that will
never change to provide predictable names. That's the whole point.

> > Make the system aware of persistent properties and use that. It can all
> > work automatically if done right.
> 
> It was done right before, at least for those of us for whom the bus order
> happens to be the order which we want for devices which are normally present
> at boot. If others need something else, fine, add that...

The other way around. If you like it how it is, keep it.

> > There is simply no "order" anymore we could rely on.
> 
> Bus address? Or does that change on reboot too...

Oh, you are coming closer. Bus addresses are the key, yes, but they have
usually nothing to do with enumerations by discovery order.

> > So start to think in the right direction and help solving the real problems
> > instead.
> 
> => fix the regression by restoring previous behaviour. That would solve the
> real problem that I'm seeing.

No we already have that problem. And removing unfixable crap, with a proper
preparation time _is_ the right fix. As said, keep it running, if you like it.

> > It has nothing to do with "faster booting",
> 
> I *could* be conflating or misunderstanding things here...


> > it's about dynamic system configuration. You can't have both at the same
> > time: hotplug and static configured systems.
> 
> Well, of course not: a static system would completely preclude the
> possibility of hotplugging.
> 
> Now, if you mean "statically configured system"... let's say "statically
> configured subsystem" instead. This tends to be PCI, IDE and maybe some
> others or parts of others, and these tend to be fixed. (Yes, I'm aware that
> there are hot-pluggable implementations...)

No, that's it. Nothing is "fixed" today. Everthing comes and goes all the
time on modern systems. If you don't use it, or unable to imagine it, that's
fine, but then start to think about it _before_ you write emails to public
lists and waste other people time.

> I don't see what the problem is with automatically allocating names in a
> reliable manner to fixed devices. If you want a fixed name for something
> hot-pluggable, fine, write some extra rules.
> 
> > But if we do it right, we can have a completely dynamic system, that works
> > reliably and is predictable.
> 
> Hmm? ISTM that we _had_ that.

We are far away from that. There is still whole lot of work to do. Again,
your sandbox may be much different from what's going on for dynamic device
management. Fine, if you are happy with it, so don't change it.

> > But that has absolutely nothing to do with device probing order, kernel
> > device names,
> 
> Er, yes it does. Device naming worked here because of them.

No, it worked if you were lucky and the system was "static enough". Read the
udev man page about %e, it is mentioned there for a long time.

> > or devfs-like naming schemes.
> 
> I didn't mention that...

It's almost the same, %e is a devfs like scheme, that doesn't make
sense if every reboot enumerates again from scratch.

> Maybe some symlinks in the static /dev should be used as seeds for
> udev-managed /dev? That'd provide some or possibly all of the fixed device
> names, avoid some rule writing, and provide the same naming for those devices
> in emergency-boot situations (where I tend to use init=/bin/sh and expect
> /dev/hdaX to be mounted).

How is that related? That's a distro issue and is a complete different
topic.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
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