[ANNOUNCE] udev 125 release

[ANNOUNCE] udev 125 release

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

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.

Re: [ANNOUNCE] udev 125 release

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

On Jul 21, Kay Sievers <kay.sievers@vrfy.org> wrote:

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

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [ANNOUNCE] udev 125 release

[Matthias Schwarzott]

On Montag, 21. Juli 2008, Kay Sievers wrote:
> 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.

> 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=Change
>Log
>
>
> 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.
>

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

Re: [ANNOUNCE] udev 125 release

[Kay Sievers]

On Mon, Jul 21, 2008 at 11:05, Marco d'Itri <md@linux.it> wrote:
> On Jul 21, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> 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?

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

Re: [ANNOUNCE] udev 125 release

[Kay Sievers]

On Mon, 2008-07-21 at 12:56 +0200, Matthias Schwarzott wrote:
> On Montag, 21. Juli 2008, Kay Sievers wrote:
> > 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.

> > 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=Change
> >Log
> >
> >
> > 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.
> >
> 
> 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.

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

/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

Re: [ANNOUNCE] udev 125 release

[David Zeuthen]

On Mon, 2008-07-21 at 12:56 +0200, Matthias Schwarzott wrote:
> 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.

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

Re: [ANNOUNCE] udev 125 release

[David Zeuthen]

(Resent, this time with the correct address for linux-hotplug)

On Mon, 2008-07-21 at 16:56 -0400, Doug Goldstein wrote:
> 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

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

> If any package uses them in anyway other then 
> through proper udev mechanisms, that package is broken and relying on
an 
> 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.

> 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

Re: [ANNOUNCE] udev 125 release

[Kay Sievers]

On Mon, 2008-07-21 at 20:06 -0400, David Zeuthen wrote:
> (Resent, this time with the correct address for linux-hotplug)
> 
> On Mon, 2008-07-21 at 16:56 -0400, Doug Goldstein wrote:
> > 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.

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

> Hardly. Kay said
> 
> > 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.
> 
> > If any package uses them in anyway other then 
> > through proper udev mechanisms, that package is broken and relying on
> an 
> > 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.

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

Sure, we have lots of packages doing that, and it is the right thing to
do.

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

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

Re: [ANNOUNCE] udev 125 release

[Doug Goldstein]

Kay Sievers wrote:
> On Mon, 2008-07-21 at 20:06 -0400, David Zeuthen wrote:
>   
>> (Resent, this time with the correct address for linux-hotplug)
>>
>> On Mon, 2008-07-21 at 16:56 -0400, Doug Goldstein wrote:
>>     
>>> 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.
>
>   
>> 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.
>
>   
>> Hardly. Kay said
>>
>>     
>>> 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.
>>
>>     
>>> If any package uses them in anyway other then 
>>> through proper udev mechanisms, that package is broken and relying on
>>>       
>> an 
>>     
>>> 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.
>
>   
>> 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.
>>     
>
> Sure, we have lots of packages doing that, and it is the right thing to
> do.
>
>   
>>> 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?
>>     
>
> 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
>
>   
I mentioned in my first e-mail that there is a symlink from /lib/udev 
already. So once again, there is no brokenness.

Re: [ANNOUNCE] udev 125 release

[David VomLehn]

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

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

Re: [ANNOUNCE] udev 125 release

[Marco d'Itri]

On Jul 29, David VomLehn <dvomlehn@cisco.com> wrote:

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

-- 
ciao,
Marco

Re: [ANNOUNCE] udev 125 release

[David VomLehn]

Marco d'Itri wrote:
> On Jul 29, David VomLehn <dvomlehn@cisco.com> wrote:
> 
>> 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.

Re: [ANNOUNCE] udev 125 release

[Marco d'Itri]

On Jul 29, David VomLehn <dvomlehn@cisco.com> wrote:

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

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

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

-- 
ciao,
Marco