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 07:47:38PM +0000, Darren Salt wrote:
>> I demand that Kay Sievers may or may not have written...
[snip]
>>> 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*,

Ouch.

(Hmm, fd* are block devices... ;-) )

> like recent SATA boxes alreay do.

I'm aware that some people were caught out by that...

> Latest then, you better start to think about this.

I'll probably notice this in time.

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

Removing hdc and leaving hdd in place (both being CDROM drives) would still
provide a predictable name for hdd. Predictable naming includes fixed naming,
but is not limited to that.

[snip]
>>> 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.

... exacerbated.

> And removing unfixable crap, with a proper preparation time _is_ the right
> fix.

I'm now left wondering why my CD symlinks script was removed. Of course, if
two runs of that (during boot) could see two different versions of
/proc/sys/dev/cdrom/info then we would appear to have the same problem...

> As said, keep it running, if you like it.

uptime++ :-)

[snip]
>>> 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. Everything comes and goes all the
> time on modern systems.

That implies continual udev/hotplug activity and lots of system load. :->

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

Sometimes you just want to write something :-)

[snip]
>>> 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.

(076)

... "The use of enumerations in todays [sic] systems where devices can come
and go at any time is not recommended."

Without this discussion, I would definitely understand that as referring to
USB (that being where devices are likely to come and go, barring failure,
here) and proceed to use %e anyway, regarding the warning as not being
applicable.

As it happens, use of %e occurs in the udev package; I have done nothing
other than installing a newer udev and, some time later, a reboot to cause
use of it locally.

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

> It's almost the same, %e is a devfs like scheme, [...]

I'd understood "devfs-like" to mean "long name such as disk/ide/disk0/part0".

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

Maybe it's something which several distributions would want and makes sense
to punt upstream; I don't know... ignore it if you like :-)

-- 
| Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk
| Debian,     | Northumberland | s zap,tartarus,org
| RISC OS     | Toon Army      | @
|   Kill all extremists!

Convention is the ruler of all.


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