new version of udev has different cd/dvd devices

I have two DVD drives:

Previous versions of udev put the first drive into /dev/cdrom and /dev/cdrw; the 2nd drive became /dev/dvdrw and perhaps some other drives that I can't recall offhand.

The latest udev (0.079) puts the second drive only for /dev/cdrom, cdrw,
dvd, and dvdrw.

Is this a deliberate policy change, some problem with my system (I had to do a manual "modprobe ide-cd"), or a packaging issue? I'd like a broad hint before I start to chase it down.

I could write my own rule, but if it's an unintentional change, then it's going to affect a lot of people (my old fstab no longer works with this new alias popping up).

  Moshe Yudkowsky
  work: http://www.Disaggregate.com
  book: http://www.PebbleAndAvalanche.com


-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Do not use %e in rules.

ciao,
Marco


-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Yes, %e will be removed in one of the next versions for that reason. It never worked reliably outside of udevstart, which is no longer recommended to use.

Yuu can match on ENV{ID_PATH} with custom rules for every device. On SUSE, the system management creates rules on installation or update, to have always the same names for optical drives, regardless of the order of discovery:

  $ cat /etc/udev/rules.d/65-cdrom.rules
  # cdrom links generated by YaST2
  #
  SUBSYSTEM="block", ENV{ID_PATH}="pci-0000:00:1f.2-scsi-1:0:0:0", SYMLINK+="cdrecorder cdrom"

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.

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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

the udev distro under Debian has these rules:

When I modify them to remove the "%e":

followed by rmmod ide-cd, modprobe ide-cd, I get the same behavior:

I.e., they're both pointing to the same drive.

udevmonitor --env reveals what the problem seems to be:

First comes the 1,1,0 drive:

Next comes the 1,0,0 drive:

In other words, the rules match either drive completely, if I'm reading the rules correctly.

In the meantime, I've modified fstab to use /dev/cdroms/cdrom{0,1}, but it'd be nice to figure out what happened here!

Moshe Yudkowsky * [email protected] * www.pobox.com/~moshe
  "The price of a tyrant's victory is eternal vigilance... This was
   once considered the price of liberty. Nothing buys what it used to."
    				-- Pat Cadigan


-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

What we were trying to explain is that you should write your own rules which statically assign specific aliases to specific devices. cd-aliases.rules even already contains an example of this.

ciao,
Marco


-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Thanks. The email from Kay arrived just after I'd sent off my previous response, and then I understood what you and he were driving at.

Thanks for your patience!

By the way, Looking through the ENV as reported, I don't see any variable such as ID_CDROM_DVD_RW, which would allow me to distinguish between a DVD-R and a DVD-RW. Am I correct that no variable exists?

  Moshe Yudkowsky
  work: http://www.Disaggregate.com
  book: http://www.PebbleAndAvalanche.com


-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

On Thu, Dec 29, 2005 at 12:29:36AM +0100, Kay Sievers wrote:

| On Wed, Dec 28, 2005 at 11:50:00PM +0100, Marco d'Itri wrote:
| > On Dec 28, Moshe Yudkowsky <[email protected]> wrote:
| > 
| > > The latest udev (0.079) puts the second drive only for /dev/cdrom, cdrw, 
| > >  dvd, and dvdrw.
| > Do not use %e in rules.
| 
| Yes, %e will be removed in one of the next versions for that reason. It
| never worked reliably outside of udevstart, which is no longer
| recommended to use.

What is recommended to use in place of udevstart for initial populating?

Actually, I'm not expecting to use udevstart. Rather, I am expecting to integrate code from udevstart and/or other parts of udev into my early userspace init program. It will start with nothing but rootfs mounted, and need some /dev entries to find devices to be mounted. Since /dev will end up being tmpfs in the end, it seems to make sense to go ahead and populate it at this point. There will only be /dev (tmpfs) and /sys (sysfs) mounted at that point in time ... no /etc ... so this is a big reason I can't just literally use udevstart as is, anyway.

-----------------------------------------------------------------------------
| Phil Howard KA9WGN       | http://linuxhomepage.com/      http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/   http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------


-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Look at the many distribution-specific scripts which walk sysfs and poke the uevent files.

ciao,
Marco

On Thu, Dec 29, 2005 at 02:36:29PM +0100, Marco d'Itri wrote:

| On Dec 29, Phil Howard <[email protected]> wrote:
| 
| > What is recommended to use in place of udevstart for initial populating?
| Look at the many distribution-specific scripts which walk sysfs and poke
| the uevent files.

So basically there isn't anything in udev?

Since I'm writing in C, I suspect udevstart would be more meaningful. One thing I'd need to explore is parsing issues for sysfs data. But how scripts would parse it could be different than what might be done in C. The first need for /dev will be long before the system could run a shell.

-----------------------------------------------------------------------------
| Phil Howard KA9WGN       | http://linuxhomepage.com/      http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/   http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------


-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

No, not in the tree. It's about a few lines of shell script.

Udevstart is dead and will stay as it is, until it will be removed at the time the "uevent" file triggers are common and udevstart is no longer needed.

Ubuntu has "udevplug" which is in C, Fedora has patched udevd to to do the "uevent" file triggers. For SUSE, I'm perfectly fine with the shell script as it is the most flexible and best to tweak and debug option for me. We will see if we end in a common solution some day.

That's just plain wrong.

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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Yeah, but we still need a way to enumerate devices in some kind of order, like we do for the cdrom devices today. So I don't think we can drop it entirely.

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

thanks,

greg k-h

-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

On Thu, Dec 29, 2005 at 05:57:23PM +0100, Kay Sievers wrote:

| On Thu, Dec 29, 2005 at 09:18:40AM -0600, Phil Howard wrote:
| > On Thu, Dec 29, 2005 at 02:36:29PM +0100, Marco d'Itri wrote:

[...]

| > The first need for /dev will be long before the system could
| > run a shell.
| 
| That's just plain wrong.

My first need for it sure is. It's in an early user space init program. Some prototype code I have worked on just a bunch of mknod(2) calls for now to set up a few devices I know my machines have. The next step in this project is to get away from statically coded devices and utilize what is in sysfs to build /dev. From there, it will then have devices it can mount filesystems with.

My project isn't really about hotplugging anything. Once the full system is up and running, then the init scripts can start up whatever deamon is needed, etc. But I need to get at least some devices made in /dev so they can be used, such as /dev/console and any block device that could have a filesystem. Other devices may be able to be deferred until later.

-----------------------------------------------------------------------------
| Phil Howard KA9WGN       | http://linuxhomepage.com/      http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/   http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------


-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

People are complaining about it because events are not received in bus order anymore, so the names randomly change (and since there is no locking often the same links is created for two devices).

But still, I'd rather keep it as long as possible since half broken is better than totally broken and I do not have a replacement ready.

ciao,
Marco

I demand that Greg KH may or may not have written...

[snip; creating static rules on-the-fly]

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.

| Darren Salt | d youmustbejoking,demon,co,uk | nr. Ashington,
| Debian,     | s zap,tartarus,org            | Northumberland
| RISC OS     | @                             | Toon Army
|   I don't ask for much, just untold riches...

You don't know what you want, and are willing to go through hell to get it.


-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Exactly. That's the reason, why it will be removed.

That doesn't makes sense. %e it conceptually completely broken and offering something that can't work does not give any value. Just get rid of _any_ simple enumeration, for exactly the same reason a kernel devfs is complete useless.

Write out a rule at discovery (from udev itself) for every unconfigured device and you get a sane enumeration, that will not change at next boot. If people want other names or different numbers, they can just edit the automatically created rules or add custom ones. SUSE does this for persistent network interface names, which works pretty well.

Writing out rules is reliable, predictable and one can understand what's going on. The %e is unfixable and will definitely die some day.

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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

We don't have any "order", that's why we can't do it that way. The persistent /dev/disk links are working without any "order", that's the model to follow, or writing out "automatic rules" to provide stable names. Everything else will just not work.

No, %e doesn't work "fine" without udevstart. Device names switch with every reboot, depending on random device response and process running time, which is unacceptable and %e must be avoided for that reason. And worse, %e does not use locking, so for parallel probing, it will return the same names for different devices, if they are requested in parallel in a short timeframe.

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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I demand that Kay Sievers may or may not have written...

So, basically, you're removing something which *worked* here because of an unrelated change which broke it.

Can you provide instances in which it *doesn't* work, given events received in bus order?

I don't think so - AFAIK, use of "%e" doesn't cause processes to hang due to implementation bugs. (And that is, AIUI, exactly why the kernel devfs is useless.)

ITYM "sane enumeration that will not change".

If, with no devices previously configured, it differs from what would be done with events sorted into bus order, I for one will consider it broken for the simple reason that it cannot be predicted from bus order.

What about device removal? What about swapping devices due to (for example) interrupt problems? What about plugging the same (hot-pluggable) device into a different port?

[snip]

I'd say exactly that about %e and module probing, as was before the event order was randomised.

Right now, to me, it looks fixable.

| Darren Salt | d youmustbejoking,demon,co,uk | nr. Ashington,
| Debian,     | s zap,tartarus,org            | Northumberland
| RISC OS     | @                             | Toon Army
|   Let's keep the pound sterling

..and the great tagline hunter crouches silently, text editor at the ready..


-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Forget "order" of devices on a system where everything can come and go at any time. The time can we configure a system once at installation is long over.
Make the system aware of persistent properties and use that. It can all work automatically if done right. There is simply no "order" anymore we could rely on. So start to think in the right direction and help solving the real problems instead.

It has nothing to do with "faster booting", it's about dynamic system configuration. You can't have both at the same time: hotplug and static configured systems. But if we do it right, we can have a completely dynamic system, that works reliable and is predictable. But that has absolutely nothing to do with device probing order, kernel device names, or devfs-like naming schemes.

Thanks,
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I demand that Kay Sievers may or may not have written...

Hmm. Drivers built into the kernel, devices require shutdown for replacement... well, that's the case for my DVD drives.

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

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

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

=> fix the regression by restoring previous behaviour. That would solve the real problem that I'm seeing.

I *could* be conflating or misunderstanding things here...

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.

Hmm? ISTM that we _had_ that.

Er, yes it does. Device naming worked here because of them.

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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

It never worked reliably for modular kernels.

Plug in/out any device on any bus, reboot and all your silly numbers will change. That's no longer acceptable with current system requirements.

No, devfs is useless, cause it simply enumerates based on discovery order, that does not help anything if devices come and go, which can happen anytime with recent kernels and stuff like pci hotplug ...

There is by concept no "sane enumeration" on a dynamic system and will never be. But seem you don't get the picture at all.

Again, seems you have absolutely no clue what all this is about, do your homework before posting such nonsense.

Nobody forces you to use it, it isn't even part of the udev tree. You can stick with what you have or whatever you think is better.

Good luck, go ahead. You will surprise me if you come up with something useful.

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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I demand that Kay Sievers may or may not have written...

Hmm. I'm using mostly monolithic, and it's failing regardless.

That's a known effect and, as such, can be routed around. For some devices, I can see that this can be a problem; but for others, it may well be perfectly acceptable.

I know that (given the previous, stable, naming) removing and not replacing the sound card here in my main Linux box would cause the on-board sound hardware to be "card 0" rather than "card 1". That's acceptable and expected (I'm allowing ALSA to automatically number them because, until fairly recently, this worked reliably).

[snip]

If the user says that "these parts of the system are static" (and I say that much of my system is static), why *shouldn't* some enumeration be considered sane?

For "bus order", read "whatever order happens to have been used by older udev which provides stable naming given the same hardware configuration". This looks like bus order from where I'm sitting.

If a newly-upgraded udev happens to generate its own rules which provide different naming, well, that's breakage right there: I could insert a disk into one CDROM drive then be surprised that I get a "drive empty" error because udev has called the wrong one (the writer, /dev/hdd) /dev/cdrom.

Do you understand that? :->

[snip]

| Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk
| Debian,     | Northumberland | s zap,tartarus,org
| RISC OS     | Toon Army      | @
|   Retrocomputing: a PC card in a Risc PC

8 End of file, 0:1


-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

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.

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.

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

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

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.

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.

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.

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.

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

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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Sure, that's expected, cause your naming rules are broken.

"Some devices" concepts are exactly that we are working on to get rid of. Why are you running an explicitely marked as "unstable" system, if you have no clue what we are working on?

Then you never used USB sound devices, like headsets or something else. Again, if you lack of the needed experience in the area or ability to imagine the picture, please stop posting this nonsense.

Cause _nothing_ is static today. Get used to it.

Repeating the same stuff again and again doesn't add any value to it.

No, definitely not. Your broken rules have renamed it. Fix them and everthing is fine.

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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I demand that Kay Sievers may or may not have written...

[snip]

I'm running what was currently in Debian testing when I last updated - 0.076-6.

In the case of USB sound devices, it is *possible* that I would already have taken the time to explicitly number those (and the others if they turned out to require numbering as a result), but I would have to have seen randomness in udev's behaviour or some appropriate warning of such randomness.

I don't know about USB headsets or speakers, though. I'm avoiding such things on the assumption that they're not compatible with my existing sound hardware.

(It still seems to me to be breaking things which may be working for some before adequate replacement is ready.)

[snip]

Then the udev package which I'm using (076) should have contained appropriate warnings. However, if this randomisation wasn't expected or noticed by the packager...

Marco, have you done this for 079?

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

RISC OS 4 easter egg E3A00002 E28F1004 E3A02000 EF00001E 55515249 736C6974 00


-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I demand that Kay Sievers may or may not have written...

[snip]

Ouch.

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

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

I'll probably notice this in time.

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]

... exacerbated.

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

uptime++ :-)

[snip]

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

Sometimes you just want to write something :-)

[snip]

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

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

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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

No. I will not waste time adding debconf warnings for this. If you would like to help then help writing whatever is needed to generate on demand the rules for static names.

ciao,
Marco


-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

The problem is we need to "name" devices reliably, without depending on discovery-order enumeration. %e is also used to enumerate over different subsystems like hd* and sr*. That probing order can't provide "stable" names.

On SUSE we never used %e for that reason and the system management creates rules for optical devices which just match on ID_PATH. That works pretty well in all currently known setups.

For systems/distros who don't have such a central system management, we may want some kind of "auto rule creation" for optical devices to provide stable names.

Something like a script that checks, if a device is already catched by a persistent rule and if not, it names the device uniquely and at the same time it drops a rule line to a file in /etc/udev/rules.d/. So the next time the device shows up, the same name gets assigned. That file can be edited by the user, if he wants a different name.

That "auto rule setup" could run from udev itself, but may not work in all cases where /etc is not writable on bootup, or it can be triggered by running the script manually, once after adding new hardware.

That sounds like the only sane and future proof option to me.

Anybody willing to try this? I shouldn't be hard to implement this as a shell script. Any code, ideas, comments?

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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I demand that Marco d'Itri may or may not have written...

A paragraph in NEWS.Debian would be adequate, I suspect.

I may have a look. Maybe my cdsymlinks script would be a good starting point...?

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

The Government spins faster than the fastest CD-ROM drive can spin a disc.


-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I have been thinking about this for a while.
So far I collected these factoids:

- there is no other component which
- it would be nice if links to CD/DVD drives were assigned in bus order, as it used to happen with %e. How?
- this does not need to be perfect, but it should not create surprises for the common cases.
- OSS sound devices are harder, there are a set of different devices whose indexes must be kept in sync.
- it should really be a shell script

ciao,
Marco

Kay> Something like a script that checks, if a device is already Kay> catched by a persistent rule and if not, it names the device Kay> uniquely and at the same time it drops a rule line to a file Kay> in /etc/udev/rules.d/. So the next time the device shows up, Kay> the same name gets assigned. That file can be edited by the Kay> user, if he wants a different name.

Kay> That "auto rule setup" could run from udev itself, but may Kay> not work in all cases where /etc is not writable on bootup, Kay> or it can be triggered by running the script manually, once Kay> after adding new hardware.

Kay> That sounds like the only sane and future proof option to me.

Kay> Anybody willing to try this? I shouldn't be hard to implement Kay> this as a shell script. Any code, ideas, comments?

* Is locking necessary to generate sequence numbers correctly? I'm not sure about this, since I haven't been following closely enough whether udev currently serialises the processing of events, which would avoid the need to lock around sequence number generation.

* Name generation can be considered orthogonal to rule generation for persistent names.

That is, name generation can be handled by something like:

    ACTION="add", ..., PROGRAM="/sbin/namegen hd %%N 0", NAME="%c"

The 1st arg to namegen is the device name prefix. The 2nd is the suffix style "%N" would use the standard letter-based enumeration, whereas '%d' would just sequentially number. The optional 3rd argument is the initial sequence number, which would default to 0 anyway.

All that is needed is a place to drop the current sequence number for each prefix.

Groups of devices with the same sequence number, such as ALSA devices, shouldn't be too much of a problem. Rules this should do the trick:

    ACTION="add", ..., PROGRAM="/sbin/namegen snd/controlC %%d 0", NAME="%c"
    ACTION="add", ..., \
      PROGRAM="/sbin/namegen snd/pcmC %%dD0c 0 snd/controlC", NAME="%c"

The extra argument to namegen indicates which sequence number to use.

I suspect something cleverer could be done using IMPORT{program} and some environment variables.

* Rule generation could be handled using a separate program. udev rules to do the generation might look like:

    ACTION="add", BUS="scsi", ENV{ID_VENDOR}="?*", ENV{ID_MODEL}="?*", \
      ENV{ID_SERIAL}="?*", RUN+="/sbin/rulegen  [...]"

The biggest trick is knowing when namegen has been called to generate a name. Instead of using PROGRAM=... above, we could use IMPORT{program}=... and then check:

    NAME=ENV{NAMEGEN_NAME}

in the above rule.

Is any of that sane? :-)

peace & happiness,
martin

-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

me too ... mainly for scsi disks.

?

A simple script that generates rules to create /dev's under (perhaps) /dev/user that are the same as the current kernel name based on a match with ID_SERIAL (of course handling name collisions and more) would be useful. Users could then edit the rule file to create "nicer" names.

IMHO, there should eventually be both command line and gui interfaces (built on top of the same underlying code), as a gui (even curses like interface) is probably better for displaying the device names and attributes, and selectively modifying policies if you have many devices/disks i.e. columns with check boxes for enabling particular policies and/or names.

Also:

- allow selection of policies, so for example, you can have by-id, by-path, or user-named. So we don't always create by-id, by-path or user-named.

The items I stumble on are:

How do you know if an attribute (mainly the id / serial number) for the device is useful as a persistent attribute? Do you assume all are invalid, valid, or what?

Should or how do you integrate this into the installer? It is bad to *not* allow naming or use of by-id at install time, but then later require it to mount root. Mount by label solves this for many but can't handle a disk being duplicated/backed up. I guess you can just run the scripts from the installer.

-- Patrick Mansfield

-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

I demand that Patrick Mansfield may or may not have written...

[snip; tool for setting udev policy]

I'm happy with whatever's there at boot and at udev startup, after modules are loaded, gets automatically enumerated (sorting by bus address, generic rules), with everything else being handled dynamically.

(I'd stick with static /dev but for hotplugging of some types of USB device.)

Not sure. My guess is "assume valid" with a blacklist of known-bad attribute values, although this could make restoring from backup after replacing or (possibly) moving some hardware somewhat interesting.

Then there's upgrading of existing installations...

| Darren Salt | nr. Ashington, | d youmustbejoking,demon,co,uk
| Debian,     | Northumberland | s zap,tartarus,org
| RISC OS     | Toon Army      | @
|   We've got Souness, we don't want him

I don't want to grow up. I won't grow up. You can't make me.


-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Debian lacks something like /sbin/hwup of SuSE, so I need a lightweight self-contained solution.

We already have stable names in /dev/disk/ and I do not think we need more. What I need is a solution for the /dev/cdrom* symlinks.

Why not?

You can't, each SUBSYSTEM needs to be special-cased.

No (at least for Debian), because the installer does not need these devices and I have to support upgrades and new devices added after the initial installation.

ciao,
Marco

So do other distros :)

Exactly. The /dev/disk solution is now adopted by all distros that use udev, so there should not be any problems with this anymore.

thanks,

greg k-h

-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Then propose an additional, friendly, way of doing things in a new subdir in /dev/disk to address these issues. I haven't heard of any complaints, why don't they make them on the linux-hotplug-devel mailing list where they might be listened to? :)

Yeah, dm does it's own thing, separate from udev. But that's dm's issue, not udev's...

thanks,

greg k-h

-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

That was kind of what I'm doing on this thread. So, use /dev/disk/user instead of /dev/user.

Because you'd flame them back to dm-devel ;-)

Yes, but they should be using udev.

Can't you NAK or flame their kernel code? :-(

[hopefully i can send email to the list via this address ...]

-- Patrick Mansfield

-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

"by-user" perhaps? Ick, I really don't like user specific things :)

Nah, am I that harsh?

That's for them to decide to use or not.

I try to stay away from dm code if I can help it :)

This list accepts email from non-subscribers just fine, only thing it doesn't like is the normal sf.net spam tests, and html email.

thanks,

greg k-h

-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Yeh.

You can also have id/serial numbers for all SCSI devices. The SCSI command (INQUIRY VPD page 0x83) is not disk specific, I think SLES9 now lists tapes under /dev/disk/by-id.

no ...

Best if all kernel and user code *can* use it in the same way, and set the same env variables (at least ID_SERIAL).

And it also blocks you if your gateway is in spam cop :-(

-- Patrick Mansfield

-------------------------------------------------------
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_id865&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel