Glad to hear that you fixed the problem, I know any issue with /dev can be pretty annoying.

Is it just me, or am I the only one who thinks that dynamically allocated device nodes is a flawed concept? What is the solution that it's trying to solve? Sure, thousands of static nodes is 'messy' and it can be frustrating when a device node exists for a piece of hardware that does not, but overall the solution in the past seems much simpler and I'm unsure why we need dynamic-/dev. At least I can't see why all users need it.

The motivation for dynamic node allocation is rule-based node naming. This is useful for removable devices, such as USB disks.

For example, the backup hard disk for my laptop has the volume label "backup", so when it's plugged in it's always at "/dev/disk/by-label/backup" . This way my backup script won't have to hunt for it._________________Personal overlay | Simple backup scheme

@infirit,
How many optical drives do you have please?
If you have 2,one rom and one rw could you please try and play a music cd in them?
I'm curious what the result is.
Thanks in advance.
Gerard._________________To install Gentoo I use sysrescuecd.Based on Gentoo,has firefox to browse Gentoo docs and mc to browse (and edit) files.
The same disk can be used for 32 and 64 bit installs.
You can follow the Handbook verbatim.
http://www.sysresccd.org/Download

@infirit,
How many optical drives do you have please?
If you have 2,one rom and one rw could you please try and play a music cd in them?

I only have 1 (LG sata bluray drive) and this one works ok with mplaye2 and cdparanoia. I may have a spare one lying around which I can put in the box. What kind of issues are you seeing?_________________EASY TO INSTALL = Difficult to install, but instruction manual has pictures.
Join the adopt an unanswered post initiative today

is wrong.
The drive I have on /dev/sr0 works fine.
The one I have on /dev/sr1 doesn't.
Looking at the code it's not surprising because it implicitly names sr0.
Computers that come with 2 optical drives (one ROM and the other RW) always have the RW on sr0 and the ROM on sr1.
Gerard._________________To install Gentoo I use sysrescuecd.Based on Gentoo,has firefox to browse Gentoo docs and mc to browse (and edit) files.
The same disk can be used for 32 and 64 bit installs.
You can follow the Handbook verbatim.
http://www.sysresccd.org/Download

is wrong.
The drive I have on /dev/sr0 works fine.
The one I have on /dev/sr1 doesn't.

You need to more specific what does not work . Is it an application, no device node created or... Does it work with the official udev provided by gentoo?

gerard82 wrote:

Looking at the code it's not surprising because it implicitly names sr0.
Computers that come with 2 optical drives (one ROM and the other RW) always have the RW on sr0 and the ROM on sr1.
Gerard.

I don't think this has ever worked properly which maybe why it was abandoned. See if the below code give any attributes you can match against.

Code:

udevadm info /dev/sr0

If it also does not work the official udev from gentoo it is not related to this fork. If this is the case then I suggest opening a separate topic in multimedia. Or write your own rules, see this howto but be advised that udevinfo has been replaced with udevadm info.

you can also use mplayer/mplayer2 to test as it allow for the device to be used. I use mplayer2 which you may need to change to mplayer (no 2).

I installed the fork on my day to day Gentoo.
Before that I didn't have this problem.
So I reverted back to the official Gentoo udev-171-r8 and all works fine.

I also have another Gentoo install for experiments.
Here I installed the fork and got it working ok concerning the optical drives by replacing the
60-cdrom_id.rules file with the one that comes with udev-171-r8 and now it works ok.
I placed it in /etc/udev/rules.d after the removing the one from lib/udev/rules.d.
It looks like this

Notice the difference.
I don't want to have to use the command line to play a cd while kde provides a pop up with the choice to either play it or rip it.
Gerard._________________To install Gentoo I use sysrescuecd.Based on Gentoo,has firefox to browse Gentoo docs and mc to browse (and edit) files.
The same disk can be used for 32 and 64 bit installs.
You can follow the Handbook verbatim.
http://www.sysresccd.org/Download

I installed the fork on my day to day Gentoo.
Before that I didn't have this problem.
So I reverted back to the official Gentoo udev-171-r8 and all works fine.

This is not about an issue with this fork. Because you run a stable system (udev version 171) you have not run into this (yet). The latest unstable version udev 195 has the same 60-cdrom_id.rules file as the fork.

gerard82 wrote:

I don't want to have to use the command line to play a cd while kde provides a pop up with the choice to either play it or rip it.
Gerard.

I understand that I was only providing a way to test if it was at all possible to play an audio cd (because you did not specify what did not work )._________________EASY TO INSTALL = Difficult to install, but instruction manual has pictures.
Join the adopt an unanswered post initiative today

Please carefully re-read my post.
Gerard._________________To install Gentoo I use sysrescuecd.Based on Gentoo,has firefox to browse Gentoo docs and mc to browse (and edit) files.
The same disk can be used for 32 and 64 bit installs.
You can follow the Handbook verbatim.
http://www.sysresccd.org/Download

Well hcaulfield57 I "fixed" it.
I removed the 60-cdrom_id.rules from /lib64/udev/rules.d.
I then copied the same rules file from udev-171-r8 to /etc/udev/rules.d and added 70-persistent-cd.rules from the same udev.
I did all this on a separate experimental Gentoo install.
Now everything on my box works.
When I load a music cd in the rom drive kde pops up a message what program I want to use to either play it or rip it.
So to me this proves the original rule is wrong.
Gerard.

Is it just me, or am I the only one who thinks that dynamically allocated device nodes is a flawed concept? What is the solution that it's trying to solve? Sure, thousands of static nodes is 'messy' and it can be frustrating when a device node exists for a piece of hardware that does not, but overall the solution in the past seems much simpler and I'm unsure why we need dynamic-/dev. At least I can't see why all users need it.

Well, some systems (e.g. OpenBSD) still use static /dev for the matter of simplicity. It is annoying sometimes, for example you don't see which hd partitions are present, etc, but it's not that bad.

Well, some systems (e.g. OpenBSD) still use static /dev for the matter of simplicity. It is annoying sometimes, for example you don't see which hd partitions are present, etc, but it's not that bad.

That's what I was thinking of specifically. I use OpenBSD, and happen to quite like it, and static /dev works well there. It's also a supported configuration on Slackware and Gentoo, I might add.

Perhaps not so much the concept of dynamic /dev is flawed, because it doesn't entirely make sense to have device nodes present for hardware that is not present, but I think static /dev is much simpler, and removes the added layer of complexity that dynamic /dev creates and removes many points of failure.

I don't use OpenBSD -- does it address the problem of consistent naming for removable devices? Certainly, if you can live without this feature you only need static nodes._________________Personal overlay | Simple backup scheme

Another question: does the OpenBSD device layer emit signals upon the insertion of devices, and are there tools to do something with these signals?

Dynamic device naming is easy if you have this in place. Arguably this is more important/general, as it allows not only device naming, but other policy-driven tasks like permissions, automounting etc.

Of course part of the discussion in this thread is that the drive for policy-based management of various system functions is leading to a bloated software stack._________________Personal overlay | Simple backup scheme

Another question: does the OpenBSD device layer emit signals upon the insertion of devices, and are there tools to do something with these signals?

Dynamic device naming is easy if you have this in place. Arguably this is more important/general, as it allows not only device naming, but other policy-driven tasks like permissions, automounting etc.

On the first point, not sure what you mean, the kernel automatically recognizes devices that are plugged in or whatever, if that's what you're asking.

On the second point, OpenBSD does not have any /sys directory like Linux where devices are stored. Although I wouldn't really say that Linux takes care of device node permissions, for instance devtmpfs will create device nodes with default permissions (can't remember what they are at the moment). Typically some userspace program is needed for proper permissions, like mdev, or udev through the uevent system in /sys. Someone can correct me if I'm wrong, but that's how I understand permissions taking place.

uevent is what I was referring to, I had forgotten what it was called. This allows you to do all kinds of fancy things in userspace, though it'd be nice if doing so weren't *required*_________________Personal overlay | Simple backup scheme

uevent is what I was referring to, I had forgotten what it was called. This allows you to do all kinds of fancy things in userspace, though it'd be nice if doing so weren't *required*

It looks like it does have a way of emitting an event of some sort for newly added devices.

What I do know is that the linux kernel caches uevents until userspace can read them. Not sure this is in place for openbsd.._________________EASY TO INSTALL = Difficult to install, but instruction manual has pictures.
Join the adopt an unanswered post initiative today

Good news and finally a good name for it too.
Next time I can post in Gentoo's bugzilla when I have a problem like no /dev/sr1,only /dev/sr0.
Gerard._________________To install Gentoo I use sysrescuecd.Based on Gentoo,has firefox to browse Gentoo docs and mc to browse (and edit) files.
The same disk can be used for 32 and 64 bit installs.
You can follow the Handbook verbatim.
http://www.sysresccd.org/Download

i have nothing to add, but wanted to pop in (again?) and leave a piece of spam -

thanks again for doing this. It's f*cking cool to see users of our humble little source based distro sending a big fat middle finger to systemd takeover, and not only that, but I read through the thread, see this pop up on bugzilla, and see it's gaining significant momentum. Bonus: the kernel devs are as annoyed with the current upstream udev as I am.

Just to make things clear: yesterday we had a nice chat with gentoo devs behind the other fork and we understand why they are doing this (politics, not technial issues or NIH). So i guess we all should wait for the results. After that we may (no certain plans for now, though) merge codebases or work together in any other way.