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

[Darren Salt <linux@youmustbejoking.demon.co.uk>]

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.

> The time can we configure a system once at installation is long over.

I don't recall making any mention of one-time configuration.

> 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...

> There is simply no "order" anymore we could rely on.

Bus address? Or does that change on reboot too...

> 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.

> 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...)

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.

> 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.

> or devfs-like naming schemes.

I didn't mention that...


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).

[snip]
-- 
| Darren Salt | d youmustbejoking,demon,co,uk | nr. Ashington,
| Debian,     | s zap,tartarus,org            | Northumberland
| RISC OS     | @                             | Toon Army
|   <URL:http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys)

There are no giant crabs in here, Frank.


-------------------------------------------------------
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