udev 125 release
Here comes a new udev version. Thanks to all who have contributed to this release.
The tarball can be found here:
ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/
The development repository can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summary
The ChangeLog can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=ChangeLog
udev 125
====
Bugfixes.
Default udev rules, which are not supposed to be edited by the user, should be placed in /lib/udev/rules.d/ now, to make it clear that they are private to the udev package and will be replaced with an update. Udev will pick up rule files from:
/lib/udev/rules.d/ - default installed rules /etc/udev/rules.d/ - user rules + on-the-fly generated rules /dev/.udev/rules.d/ - temporary non-persistent rules created after bootup
It does not matter in which directory a rule file lives, all files are sorted in lexical order.
To help creating /dev/root, we have now:
$ udevadm info --export --export-prefix="ROOT_" --device-id-of-file=/ ROOT_MAJOR=8 ROOT_MINOR=5 In case the current --device-id-of-file is already used, please switch to the --export format version, it saves the output parsing and the old format will be changed to use ':' as a separator, like the format in the sysfs 'dev' file.
Quoted 3 lines · Kay Sievers
Default udev rules, which are not supposed to be edited by the user, should be placed in
/lib/udev/rules.d/now, to make it clear that they are private to the udev package and will be replaced with an update. Udev will pick up rule
Is this required by distributions which have troubles managing modified configuration files or do you have more complex plans?
Signature · 2 lines
ciao, Marco
Quoted 6 lines · Kay Sievers
Here comes a new udev version. Thanks to all who have contributed to this release.
The tarball can be found here:
ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/
Well, it is not yet there.
Quoted 13 lines
The development repository can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summaryThe ChangeLog can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=Change
Logudev 125
====
Bugfixes.
Quoted 10 lines
Default udev rules, which are not supposed to be edited by the user, should be placed in
/lib/udev/rules.d/now, to make it clear that they are private to the udev package and will be replaced with an update. Udev will pick up rule files from:
/lib/udev/rules.d/- default installed rules/etc/udev/rules.d/- user rules + on-the-fly generated rules/dev/.udev/rules.d/- temporary non-persistent rules created after bootup
It does not matter in which directory a rule file lives, all files are sorted in lexical order.
And I wanted to ask the same question as Marco: Do distributions need to move these rules to /lib/udev/rules.d/ ?
We on gentoo do use /lib64/udev to be strict on systems using 32 and 64 bit libraries, so the rules end in /lib64/udev/rules.d if we choose this way.
Regards
Matthias
Quoted 7 lines · Marco d'Itri
Quoted 3 lines · Kay Sievers
Default udev rules, which are not supposed to be edited by the user, should be placed in
/lib/udev/rules.d/now, to make it clear that they are private to the udev package and will be replaced with an update. Udev will pick up ruleIs this required by distributions which have troubles managing modified configuration files or do you have more complex plans?
We just want to split package owned rules from user/on-demand created rules. Most of the udev rules files are static databases and must not be changed, therefore do not belong in /etc. Everything will continue to work as today, if system want to use /etc only, but we suggest to move things which are not supposed to be changed by users/admins to the private rules directory.
Thanks,
Kay
Quoted 8 lines · Matthias Schwarzott
Quoted 6 lines · Kay Sievers
Here comes a new udev version. Thanks to all who have contributed to this release.
The tarball can be found here:
ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/Well, it is not yet there.
Should be there now. Sorry, forgot to copy it.
Quoted 24 lines
Quoted 13 lines
The development repository can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summaryThe ChangeLog can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=Change
Logudev 125
====
Bugfixes.Quoted 10 lines
Default udev rules, which are not supposed to be edited by the user, should be placed in
/lib/udev/rules.d/now, to make it clear that they are private to the udev package and will be replaced with an update. Udev will pick up rule files from:
/lib/udev/rules.d/- default installed rules/etc/udev/rules.d/- user rules + on-the-fly generated rules/dev/.udev/rules.d/- temporary non-persistent rules created after bootup
It does not matter in which directory a rule file lives, all files are sorted in lexical order.
Quoted 2 lines
And I wanted to ask the same question as Marco: Do distributions need to move these rules to
/lib/udev/rules.d/?
No, but it's suggested that /etc will only contain stuff that can be edited by users/admins. But everything will work the same way as before if /lib/udev/rules.d/ is not used.
Quoted 2 lines
We on gentoo do use
/lib64/udevto be strict on systems using 32 and 64 bit libraries, so the rules end in/lib64/udev/rules.dif we choose this way.
/lib/udev/ is udev's private directory on _every_ system, as LSB defines. There is no single library in /lib/udev/, the translation to /lib64/udev/ is broken in exactly the same way you would introduce /sbin64/udevd. I suggest you fix that, instead of trying to work around the problems it creates.
Thanks,
Kay
Quoted 2 lines · Matthias Schwarzott
We on gentoo do use
/lib64/udevto be strict on systems using 32 and 64 bit libraries, so the rules end in/lib64/udev/rules.dif we choose this way.
In a very real way, /lib/udev is part of the ABI offered by udev. So by changing this you're breaking third party software that depends on this ABI (e.g. by dropping programs in that tree). Please avoid breaking upstream ABI. Thanks.
David
(Resent, this time with the correct address for linux-hotplug)
Quoted 4 lines · Doug Goldstein
Firstly, there's an inherit symlink that occurs anyway so there is no ABI breakage. And secondly, Kay has clearly stated that these are private rules for udev and udev alone. They ship with udev and are replaced only by udev.
Hardly. Kay said
Quoted 2 lines
but we suggest to move things which are not supposed to be changed by users/admins to the private rules directory.
Now please explain why on earth 3rd party packages would use the directory /etc/udev/rules.d instead of /lib/udev/rules.d? If they did they would suffer from exactly the same problems as Kay is trying to solve for udev. It just doesn't make sense to consider /lib/udev an implementation detail only. There in lies madness.
Quoted 2 lines
If any package uses them in anyway other then
through proper udev mechanisms, that package is broken and relying on
an
Quoted 3 lines
unstable "ABI". If you can even consider files which are private to a package which shouldn't be edited to be an Application Binary Interface...
It seems like you thought I wrote "/lib/udev/rules.d" instead of "/lib/udev". Please read my mail again. FWIW, some packages on my Fedora system (bluez-utils, initscripts among others) already put stuff in /lib/udev and I bet it's similar on most distros.
Quoted 1 line
I believe that was a bit of a stretch to use those terms.
Not at all. But I don't really want to discuss this with you. Let's instead just query Kay about whether it's fine to consider /lib/udev as an ABI, e.g. in particular whether it's fine for 3rd party packages to drop files in /lib/udev and /lib/udev/rules.d. Kay?
David
Quoted 6 lines · David Zeuthen
(Resent, this time with the correct address for linux-hotplug)
Quoted 3 lines · Doug Goldstein
Firstly, there's an inherit symlink that occurs anyway so there is no ABI breakage. And secondly, Kay has clearly stated that these are private rules for udev and udev alone.
No, I stated that rules which are not supposed to be edited should move to /lib/udev/rules.d/, including the stuff from all the other packages.
Quoted 1 line
They ship with udev and are replaced only by udev.
The udev owned rules are only replaced by udev, sure. But other packages use that too. /etc/udev/rules.d/ should be only for on-demand, or user created rules. Just think of a fully converted system, where you could do "rm /etc/udev/rules.d/*" if you want to start from scratch.
Quoted 11 lines
Hardly. Kay said
Quoted 2 lines
but we suggest to move things which are not supposed to be changed by users/admins to the private rules directory.
Now please explain why on earth 3rd party packages would use the directory
/etc/udev/rules.dinstead of/lib/udev/rules.d? If they did they would suffer from exactly the same problems as Kay is trying to solve for udev. It just doesn't make sense to consider/lib/udevan implementation detail only. There in lies madness.
Quoted 6 lines
Quoted 2 lines
If any package uses them in anyway other then
through proper udev mechanisms, that package is broken and relying onan
Quoted 3 lines
unstable "ABI". If you can even consider files which are private to a package which shouldn't be edited to be an Application Binary Interface...
They are "private to a package" in a sense that the user/admin has not to touch it, and they get replaced on package update without any warning.
Quoted 4 lines
It seems like you thought I wrote "
/lib/udev/rules.d" instead of "/lib/udev". Please read my mail again. FWIW, some packages on my Fedora system (bluez-utils, initscripts among others) already put stuff in/lib/udevand I bet it's similar on most distros.
Sure, we have lots of packages doing that, and it is the right thing to do.
Quoted 6 lines
Quoted 1 line
I believe that was a bit of a stretch to use those terms.
Not at all. But I don't really want to discuss this with you. Let's instead just query Kay about whether it's fine to consider
/lib/udevas an ABI, e.g. in particular whether it's fine for 3rd party packages to drop files in/lib/udevand/lib/udev/rules.d. Kay?
Absolutely, /lib/udev/ _is_ a public interface, and the only place supported by udev. /lib64/udev/ is a broken installation. The source code even hard-codes that path in some cases. It is intentionally not configurable.
LSB suggests directories like this, it is well defined, that part of LSB makes a lot of sense, and we use it that way.
3rd parties use it, and do not need to care where they will find it, every properly installed system has it at /lib/udev/.
/lib64/ is for libraries, we do not ship any, and if we do, we sure will put them in /lib64/, and not in /lib/udev/. But still, only the libs, not any other files. As long as people do not have /sbin64/ and such, the whole discussion about multi-arch for non-libraries is completely superfluous anyway.
Matthias, Doug, it would be nice, if you can fix the udev package on Gentoo, it is broken to use /lib64/udev/.
Btw, where are your kernel modules? In /lib64/modules/?
Thanks,
Kay
Quoted 87 lines · Kay Sievers
Quoted 8 lines · David Zeuthen
(Resent, this time with the correct address for linux-hotplug)
Quoted 4 lines · Doug Goldstein
Firstly, there's an inherit symlink that occurs anyway so there is no ABI breakage. And secondly, Kay has clearly stated that these are private rules for udev and udev alone.
No, I stated that rules which are not supposed to be edited should move to
/lib/udev/rules.d/, including the stuff from all the other packages.Quoted 2 lines
They ship with udev and are replaced only by udev.
The udev owned rules are only replaced by udev, sure. But other packages use that too.
/etc/udev/rules.d/should be only for on-demand, or user created rules. Just think of a fully converted system, where you could do "rm/etc/udev/rules.d/*" if you want to start from scratch.Quoted 13 lines
Hardly. Kay said
Quoted 3 lines
but we suggest to move things which are not supposed to be changed by users/admins to the private rules directory.
Now please explain why on earth 3rd party packages would use the directory
/etc/udev/rules.dinstead of/lib/udev/rules.d? If they did they would suffer from exactly the same problems as Kay is trying to solve for udev. It just doesn't make sense to consider/lib/udevan implementation detail only. There in lies madness.Quoted 9 lines
Quoted 3 lines
If any package uses them in anyway other then
through proper udev mechanisms, that package is broken and relying onan
Quoted 4 lines
unstable "ABI". If you can even consider files which are private to a package which shouldn't be edited to be an Application Binary Interface...
They are "private to a package" in a sense that the user/admin has not to touch it, and they get replaced on package update without any warning.
Quoted 5 lines
It seems like you thought I wrote "
/lib/udev/rules.d" instead of "/lib/udev". Please read my mail again. FWIW, some packages on my Fedora system (bluez-utils, initscripts among others) already put stuff in/lib/udevand I bet it's similar on most distros.Sure, we have lots of packages doing that, and it is the right thing to do.
Quoted 7 lines
Quoted 2 lines
I believe that was a bit of a stretch to use those terms.
Not at all. But I don't really want to discuss this with you. Let's instead just query Kay about whether it's fine to consider
/lib/udevas an ABI, e.g. in particular whether it's fine for 3rd party packages to drop files in/lib/udevand/lib/udev/rules.d. Kay?Absolutely,
/lib/udev/_is_ a public interface, and the only place supported by udev./lib64/udev/is a broken installation. The source code even hard-codes that path in some cases. It is intentionally not configurable.LSB suggests directories like this, it is well defined, that part of LSB makes a lot of sense, and we use it that way.
3rd parties use it, and do not need to care where they will find it, every properly installed system has it at
/lib/udev/.
/lib64/is for libraries, we do not ship any, and if we do, we sure will put them in/lib64/, and not in/lib/udev/. But still, only the libs, not any other files. As long as people do not have /sbin64/ and such, the whole discussion about multi-arch for non-libraries is completely superfluous anyway.
Quoted 9 lines
Matthias, Doug, it would be nice, if you can fix the udev package on Gentoo, it is broken to use
/lib64/udev/.Btw, where are your kernel modules? In
/lib64/modules/?Thanks,
Kay
I mentioned in my first e-mail that there is a symlink from /lib/udev already. So once again, there is no brokenness.
Quoted 8 lines
udev 125
====
Bugfixes.Default udev rules, which are not supposed to be edited by the user, should be placed in
/lib/udev/rules.d/now, to make it clear that they are private to the udev package and will be replaced with an update. Udev will pick up rule files from:
...
Quoted 1 line
/etc/udev/rules.d/- user rules + on-the-fly generated rules
...
I think there is a problem. The Filesystem Hierarchy Standard states (See
http://www.pathname.com/fhs/pub/fhs-2.3.html#ETCHOSTSPECIFICSYSTEMCONFIGURATION):
Quoted 2 lines
The /etc hierarchy contains configuration files. A "configuration file" is a local file used to control the operation of a program; it must be static...
If I understand what is meant by "on-the-fly generated rules", these are not static and so don't belong under /etc. I think an FHS-conforming place for these would be under /var somewhere, such as /var/lib/udev. Placing them under /etc can be an issue for embedded systems where /etc is frequently read-only.
- - - - - Cisco - - - - -
This e-mail and any attachments may contain information which is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer.
Quoted 3 lines · David VomLehn
If I understand what is meant by "on-the-fly generated rules", these are not static and so don't belong under /etc. I think an FHS-conforming place for these would be under /var somewhere, such as
/var/lib/udev.
/var may not be available yet when the files are needed, arguing to move them there is pointless.
Also, they can be edited manually while /var data cannot.
Signature · 2 lines
ciao, Marco
Quoted 6 lines · Marco d'Itri
Quoted 1 line · David VomLehn
If I understand what is meant by "on-the-fly generated rules", these are not static and so don't belong under /etc. I think an FHS-conforming place for these would be under /var somewhere, such as
/var/lib/udev./var may not be available yet when the files are needed, arguing to move them there is pointless.
Also, they can be edited manually while /var data cannot.
I don't know of any problems with editing /var data manually, but your point about /var not being available early enough to run udev is certainly an important point to consider.
Note that embedded systems are not the only case where read-only root filesystems may arise. They are also used when your root filesystem is on a CDROM or DVD, or when you have a read-only root filesystem so you can network-mount it on multiple nodes. These cases influenced the Filesystem Hierarchy Standard people to make /etc read-only. So, I think that using /etc for "on-the-fly" generated udev rules is an issue in a number of situations.
This looks like it might be a chicken-and-egg issue, where you may need to run udev in order to be able to mount a writable filesystem in which to store rules used by udev. I'm no expert on udev and what drove the need for this feature, but is it possible that you wouldn't need to generate rules *on-the-fly* until after mounting /var? If that were the case, you could still put the generated rules there.
Another possibility is simply to add a /var/lib/udev directory to the directories in which rules may reside. If you have a read-only root filesystem, you'll just have to mount /var before you can generate your own rules.
- - - - - Cisco - - - - -
This e-mail and any attachments may contain information which is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer.
Quoted 2 lines · David VomLehn
Quoted 1 line
Also, they can be edited manually while /var data cannot.
I don't know of any problems with editing /var data manually, but your
It's one of the basic rules which have always defined /var. From FHS 2.3:
/var/lib : Variable state information
Purpose
This hierarchy holds state information pertaining to an application or the system. State information is data that programs modify while they run, and that pertains to one specific host. Users must never need to modify files in /var/ lib to configure a package's operation.
Quoted 7 lines
Note that embedded systems are not the only case where read-only root filesystems may arise. They are also used when your root filesystem is on a CDROM or DVD, or when you have a read-only root filesystem so you can network-mount it on multiple nodes. These cases influenced the Filesystem Hierarchy Standard people to make /etc read-only. So, I think that using /etc for "on-the-fly" generated udev rules is an issue in a number of situations.
Live CDs do not really need persistent status and in my experience both these and embedded systems tend to use lots of special-purpose hacks anyway.
The generated rules *are* a configuration file and there are endless generated configuration files in /etc (tipically they are generated once at install time, but on most systems the same applies to udev too).
If you have a R/O /etc an no human administrator which can edit system files then just copy the rules files from /dev/.udev/rules.d/ to /var and restore them at the next boot before udevtrigger is run.
Quoted 3 lines
need for this feature, but is it possible that you wouldn't need to generate rules *on-the-fly* until after mounting /var? If that were the case, you could still put the generated rules there.
It does not matter when they are generated but when they are used, e.g. they may be needed to NFS-mount /var.
At least on Debian systems, networking is started before even local file systems are mounted.
Signature · 2 lines
ciao, Marco