udev in initrd

[Thomas Woerner]

There are test packages in http://people.redhat.com/twoerner/UDEV/ for using 
udev in initrd with persistent devices.

Usage
-----

- If you want to enable udev in initrd, then install the test packages and
   create an initrd with mkinitrd.
- If you want to turn off udev, set USE_UDEV="no" in /etc/sysconfig/udev.
- For another udev root directory (not /dev) set udev_root="/some dir/" in
   /etc/udev/udev.conf - This will not disable udev in initrd. The result is an
   unusable initrd
- For disabling persistent /dev filesystem set UDEV_KEEP_DEV="no" in
   /etc/sysconfig/udev. Your /dev filesystem will not be the same in inird and
   the running system.
- You have to recreate the initrd after changing any of these options.

Warnings
--------

- The new mkinitrd is not tested heavily (especially lvm support).
- It will not work with devfs.
- Make a backup copy of the original initrd (best is to make an additional
   boot entry in grub with the new initrd)

Information about udev and the new mkinitrd
-------------------------------------------

The benefit of udev is that there are only those device nodes which are bound 
to devices in your computer and that you can have additional device naming 
schemes like 'by label' or 'by id'.
However there is a small problem with dynamic device nodes: For all devices, 
which are not recognized before a specific module is loaded, there will be no 
device node until the driver is loaded either by hand of by a program. kudzu 
would be a good candidate for this, but it has to be started earlier, then.

udev is using helpers for additional device naming schemes, which are c 
programs or shell scripts. Therefore it is necessary to put tools like sed, 
awk, grep and so on in the initrd. These programs are not small and the initrd 
would be very big. The solution for this is to use a static compiled busybox, 
which combines tiny versions of many utilities into a single executable.

Thus the new mkinitrd is using busybox for the initrd with udev support. 
Disabling udev results in a normal initrd with nash. It is easy to modify 
mkinitrd to build the normal initrd with busybox.

Here are the flowcharts for the standard initrd of fc2 (without lvm support) 
and the udev version:

Standard initrd - using nash
----------------------------
1) mount /proc and /sys in initrd
2) load modules (eg: controller, filesystem)
3) umount /sys
4) locate root device
5) create block devices
6) mount system root on /sysroot
7) change root to /sysroot and initrd to /sysroot/initrd
8) umount /initrd/proc

udev initrd - using busybox and ramfs
-------------------------------------
1) mount /proc and /sys
2) mount /dev as ramfs
3) create initial devices (eg: console, null, zero, loopX) and links for std
    files
4) start udev, use udevsend as hotplug
5) load modules (eg. controller, filesystem)
6) umount /sys
7) locate root device
8) mount system root on /sysroot
9) bind /dev to /sysroot [UDEV_KEEP_DEV="yes"]
10) change root to /sysroot and initrd to /sysroot/initrd
11) umount /initrd/proc
12) umount /initrd/dev [UDEV_KEEP_DEV="yes"]

Have fun,
Thomas

[Greg KH]

On Fri, May 28, 2004 at 06:05:13PM +0200, Thomas Woerner wrote:
> There are test packages in http://people.redhat.com/twoerner/UDEV/ for 
> using udev in initrd with persistent devices.

Sweet, thanks for posting this, I really appreciate it.

One small question:
> udev initrd - using busybox and ramfs
> mount /proc and /sys
> mount /dev as ramfs
> create initial devices (eg: console, null, zero, loopX) and links for std
> files
> start udev, use udevsend as hotplug

What do you do to "start udev"?  Run udevstart?
> load modules (eg. controller, filesystem)
> umount /sys
> locate root device
> mount system root on /sysroot
> bind /dev to /sysroot [UDEV_KEEP_DEV="yes"]
> change root to /sysroot and initrd to /sysroot/initrd
> umount /initrd/proc
> umount /initrd/dev [UDEV_KEEP_DEV="yes"]

Are you looking into making a initramfs instead of a initrd for the next
FC3 release?

thanks,

greg k-h

[Jeremy Katz]

On Fri, 2004-05-28 at 16:29 -0700, Greg KH wrote:
> On Fri, May 28, 2004 at 06:05:13PM +0200, Thomas Woerner wrote:
> > start udev, use udevsend as hotplug
>
> What do you do to "start udev"?  Run udevstart?

Reading the code, yes :)
> Are you looking into making a initramfs instead of a initrd for the next
> FC3 release?

I've yet to be convinced of initramfs really being better...  having to
shove your initial filesystem (whatever you want to call it :) at the
end of the kernel binary image is a major pain for usability.  It's
actually one of my biggest gripes about dealing with the iSeries
platform is that you have to make the combined kernel + initrd blob
which is fairly non-intuitive to a user and makes it really hard to
debug what's going on since you don't have a discrete file that you can
ask the user to send you.

Jeremy

[Jeremy Katz]

On Fri, 2004-05-28 at 18:05 +0200, Thomas Woerner wrote:
> There are test packages in http://people.redhat.com/twoerner/UDEV/ for using 
> udev in initrd with persistent devices.

Note, all of my comments here are just from looking at the changes and
not actually trying them yet.  I'll try to get to that later tonight,
though.
> Information about udev and the new mkinitrd
>
> The benefit of udev is that there are only those device nodes which are bound 
> to devices in your computer and that you can have additional device naming 
> schemes like 'by label' or 'by id'.
> However there is a small problem with dynamic device nodes: For all devices, 
> which are not recognized before a specific module is loaded, there will be no 
> device node until the driver is loaded either by hand of by a program. kudzu 
> would be a good candidate for this, but it has to be started earlier, then.

The smaller /dev is of arguable benefit.  Users shouldn't be looking
in /dev directly really since even with udev, it's going to be fairly
ugly.  And as of yet, I haven't seen a "good" other device naming
scheme.  I think that this is vitally important to any attempt to
actually switching to use udev.  If we keep the same device naming, I
really see little benefit here.
> udev is using helpers for additional device naming schemes, which are c 
> programs or shell scripts. Therefore it is necessary to put tools like sed, 
> awk, grep and so on in the initrd. These programs are not small and the initrd 
> would be very big. The solution for this is to use a static compiled busybox, 
> which combines tiny versions of many utilities into a single executable.

What helpers specifically?  Can we simplify these to not require lots of
additional tools?  Or use a scheme that doesn't require lots of
different additional tools?  We don't necessarily have to support every
conceivable naming scheme in the world for within the initrd.
> Thus the new mkinitrd is using busybox for the initrd with udev support. 
> Disabling udev results in a normal initrd with nash. It is easy to modify 
> mkinitrd to build the normal initrd with busybox.

Hmmm, this uglifies mkinitrd a lot.  Having two completely separate
paths for the initrd is completely unmaintainable for the long-term.  I
think that I'd rather cut the busybox down to just the minimal set of
tools needed and then still use nash as the base shell.  And actually,
getting it so that we're using the main busybox instead of
busybox-initrd would be nice (I need to look at the anaconda specific
config differences so that I can try to merge those to not require a
weird subpackage).  This would be especially as there are a few
"features" in nash that aren't going to be in a standard shell (things
like handling of quiet mode, the simple mkdmnod present, etc)
> udev initrd - using busybox and ramfs
> mount /proc and /sys
> mount /dev as ramfs
> create initial devices (eg: console, null, zero, loopX) and links for std
>  files

This looks/feels a little ugly.  But there's probably some shell that
could make it a little bit cleaner.
> start udev, use udevsend as hotplug
> load modules (eg. controller, filesystem)
> umount /sys
> locate root device

I don't like this at all.  For one thing, doesn't it currently break
with root=LABEL=/?  Is there a reason not to just use /dev/root here as
we currently do?
> mount system root on /sysroot
> bind /dev to /sysroot [UDEV_KEEP_DEV="yes"]
> change root to /sysroot and initrd to /sysroot/initrd
> umount /initrd/proc
> umount /initrd/dev [UDEV_KEEP_DEV="yes"]

Having the case of using udev in your initrd but not using it for /dev
on your installed system seems like a fairly ridiculous case that just
complicates things.  Either you're using udev for the system or not.
This then lets us drop out the /etc/sysconfig/udev handling from within
mkinitrd.

Jeremy

[Harald Hoyer]

Jeremy Katz wrote:
> What helpers specifically?  Can we simplify these to not require lots of
> additional tools?  Or use a scheme that doesn't require lots of
> different additional tools?  We don't necessarily have to support every
> conceivable naming scheme in the world for within the initrd.

right, but we have to give the user the freedom of choice here also.
> Hmmm, this uglifies mkinitrd a lot.  Having two completely separate
> paths for the initrd is completely unmaintainable for the long-term.  I
> think that I'd rather cut the busybox down to just the minimal set of
> tools needed and then still use nash as the base shell.  And actually,
> getting it so that we're using the main busybox instead of
> busybox-initrd would be nice (I need to look at the anaconda specific
> config differences so that I can try to merge those to not require a
> weird subpackage).  This would be especially as there are a few
> "features" in nash that aren't going to be in a standard shell (things
> like handling of quiet mode, the simple mkdmnod present, etc)

well, /sbin/busybox and /sbin/busybox-initrd are linked dynamically to 
glibc. As I now recognized, that dietlibc is only available on i386, we 
may think of using klibc or pulling in the whole glibc (as we do on 
s390). More freedom in initrd is IMHO a good thing, and we really can 
spare some MB these days.
> > udev initrd - using busybox and ramfs
> > mount /proc and /sys
> > mount /dev as ramfs
> > create initial devices (eg: console, null, zero, loopX) and links for std
> > files
>
> This looks/feels a little ugly.  But there's probably some shell that
> could make it a little bit cleaner.

console, null, zero are not really needed, they get created by udev. If 
the loop kernel module would provide its kernel interfaces in /sys, then 
that would also be not necessary.
Why should we hide basic operations like
         ln -snf /proc/self/fd /dev/fd
         ln -snf /proc/self/fd/0 /dev/stdin
         ln -snf /proc/self/fd/1 /dev/stdout
         ln -snf /proc/self/fd/2 /dev/stderr
         ln -snf /proc/kcore /dev/core
behind some obscure compiled-in nash feature?
> > start udev, use udevsend as hotplug
> > load modules (eg. controller, filesystem)
> > umount /sys
> > locate root device
>
> I don't like this at all.  For one thing, doesn't it currently break
> with root=LABEL=/?  Is there a reason not to just use /dev/root here as
> we currently do?

It does not brake root=LABEL, cause we patched busybox-mount to cope 
with mount-by-label. /dev/root is as ugly, as compiled-in nash device 
creating.
> > mount system root on /sysroot
> > bind /dev to /sysroot [UDEV_KEEP_DEV="yes"]
> > change root to /sysroot and initrd to /sysroot/initrd
> > umount /initrd/proc
> > umount /initrd/dev [UDEV_KEEP_DEV="yes"]
>
> Having the case of using udev in your initrd but not using it for /dev
> on your installed system seems like a fairly ridiculous case that just
> complicates things.  Either you're using udev for the system or not.
> This then lets us drop out the /etc/sysconfig/udev handling from within
> mkinitrd.

Well, if you want persistent ownerships and special devices for which 
the kernel does not provide an interface, you may want to keep /dev on a 
harddisk. Freedom of choice again.

Harald

[Harald Hoyer]

Harald Hoyer wrote:
> well, /sbin/busybox and /sbin/busybox-initrd are linked dynamically to 
> glibc.

s/-initrd/-anaconda/

[Jeremy Katz]

On Wed, 2004-06-02 at 10:16 +0200, Harald Hoyer wrote:
> Jeremy Katz wrote:
> > What helpers specifically?  Can we simplify these to not require lots of
> > additional tools?  Or use a scheme that doesn't require lots of
> > different additional tools?  We don't necessarily have to support every
> > conceivable naming scheme in the world for within the initrd.
>
> right, but we have to give the user the freedom of choice here also.

There's a point at which you just have to say that there's too much
choice.  There's nothing that says they _have_ to use our mkinitrd.  If
they want to use something other than our naming scheme, maybe they need
to use something else then.  That's not necessarily unreasonable.
> > Hmmm, this uglifies mkinitrd a lot.  Having two completely separate
> > paths for the initrd is completely unmaintainable for the long-term.  I
> > think that I'd rather cut the busybox down to just the minimal set of
> > tools needed and then still use nash as the base shell.  And actually,
> > getting it so that we're using the main busybox instead of
> > busybox-initrd would be nice (I need to look at the anaconda specific
> > config differences so that I can try to merge those to not require a
> > weird subpackage).  This would be especially as there are a few
> > "features" in nash that aren't going to be in a standard shell (things
> > like handling of quiet mode, the simple mkdmnod present, etc)
>
> well, /sbin/busybox and /sbin/busybox-initrd are linked dynamically to 
> glibc. As I now recognized, that dietlibc is only available on i386, we 
> may think of using klibc or pulling in the whole glibc (as we do on 
> s390). More freedom in initrd is IMHO a good thing, and we really can 
> spare some MB these days.

There have been requests for busybox to be statically linked, so that's
not necessarily a reason not to.  I'm not sure that switching to klibc
buys us that much.  As far as sparing some space, any space increase
directly correlates to needing to bump RAMDISK_SIZE.  Which is doable,
it just needs thinking.
> > > udev initrd - using busybox and ramfs
> > > mount /proc and /sys
> > > mount /dev as ramfs
> > > create initial devices (eg: console, null, zero, loopX) and links for std
> > > files
> >
> > This looks/feels a little ugly.  But there's probably some shell that
> > could make it a little bit cleaner.
>
> console, null, zero are not really needed, they get created by udev. If 
> the loop kernel module would provide its kernel interfaces in /sys, then 
> that would also be not necessary.

What interfaces don't get provided?  Let's get that fixed instead of
sticking our fingers in our ears and working around the fact that the
kernel is busted ;)
> Why should we hide basic operations like
>          ln -snf /proc/self/fd /dev/fd
>          ln -snf /proc/self/fd/0 /dev/stdin
>          ln -snf /proc/self/fd/1 /dev/stdout
>          ln -snf /proc/self/fd/2 /dev/stderr
>          ln -snf /proc/kcore /dev/core
> behind some obscure compiled-in nash feature?

I'm not saying we necessarily should -- even just using some slightly
different syntax could make it look a little bit cleaner.
> > > start udev, use udevsend as hotplug
> > > load modules (eg. controller, filesystem)
> > > umount /sys
> > > locate root device
> >
> > I don't like this at all.  For one thing, doesn't it currently break
> > with root=LABEL=/?  Is there a reason not to just use /dev/root here as
> > we currently do?
>
> It does not brake root=LABEL, cause we patched busybox-mount to cope 
> with mount-by-label. /dev/root is as ugly, as compiled-in nash device 
> creating.

Is it any more ugly than running sed?  I'm also not 100% convinced I
can't break that sed statement, but my sed-foo isn't super strong.
> > > mount system root on /sysroot
> > > bind /dev to /sysroot [UDEV_KEEP_DEV="yes"]
> > > change root to /sysroot and initrd to /sysroot/initrd
> > > umount /initrd/proc
> > > umount /initrd/dev [UDEV_KEEP_DEV="yes"]
> >
> > Having the case of using udev in your initrd but not using it for /dev
> > on your installed system seems like a fairly ridiculous case that just
> > complicates things.  Either you're using udev for the system or not.
> > This then lets us drop out the /etc/sysconfig/udev handling from within
> > mkinitrd.
>
> Well, if you want persistent ownerships and special devices for which 
> the kernel does not provide an interface, you may want to keep /dev on a 
> harddisk. Freedom of choice again.

If you want that, then don't use udev.  If we think that a lot of people
are going to fall into this category, then we need to re-examine the
situation because I think that that is _worse_ than our current setup.
If we're going to start using udev, then it needs to provide a tangible
benefit to users.  Just doing it so that we can say that we're using
udev isn't worth it.

Jeremy

[Thomas Woerner]

Jeremy Katz wrote:
> On Fri, 2004-05-28 at 18:05 +0200, Thomas Woerner wrote:
> > There are test packages in http://people.redhat.com/twoerner/UDEV/ for using 
> > udev in initrd with persistent devices.
>
> Note, all of my comments here are just from looking at the changes and
> not actually trying them yet.  I'll try to get to that later tonight,
> though.

Have you tried it out, yet? :-)
> > Thus the new mkinitrd is using busybox for the initrd with udev support. 
> > Disabling udev results in a normal initrd with nash. It is easy to modify 
> > mkinitrd to build the normal initrd with busybox.
>
> Hmmm, this uglifies mkinitrd a lot.  Having two completely separate
> paths for the initrd is completely unmaintainable for the long-term.  I
> think that I'd rather cut the busybox down to just the minimal set of
> tools needed and then still use nash as the base shell.  And actually,
> getting it so that we're using the main busybox instead of
> busybox-initrd would be nice (I need to look at the anaconda specific
> config differences so that I can try to merge those to not require a
> weird subpackage).  This would be especially as there are a few
> "features" in nash that aren't going to be in a standard shell (things
> like handling of quiet mode, the simple mkdmnod present, etc)

This is a test package. I patched mkinitrd to use busybox for udev support
only, the non-udev version is the working fallback for the user.

nash is not needed anymore with busybox::ash and busybox::linuxrc. Why using 
and maintaining an own tool if there is nearly the same in busybox, already?
> > udev initrd - using busybox and ramfs
> > mount /proc and /sys
> > mount /dev as ramfs
> > create initial devices (eg: console, null, zero, loopX) and links for std
> > files
>
> This looks/feels a little ugly.  But there's probably some shell that
> could make it a little bit cleaner.

Why not make this transparent for the user? It is not useful to hide this 
information - it is not a secret.
> > start udev, use udevsend as hotplug
> > load modules (eg. controller, filesystem)
> > umount /sys
> > locate root device
>
> I don't like this at all.  For one thing, doesn't it currently break
> with root=LABEL=/?  Is there a reason not to just use /dev/root here as
> we currently do?

/dev/root might be nice to look at, but it is not necessary and transparent at 
all. The real boot device is available and can be used directly. LABEL=X is 
also supported in the busybox::mount test version.

Thomas

[Jeremy Katz]

On Wed, 2004-06-02 at 12:33 +0200, Thomas Woerner wrote:
> Jeremy Katz wrote:
> > On Fri, 2004-05-28 at 18:05 +0200, Thomas Woerner wrote:
> > Hmmm, this uglifies mkinitrd a lot.  Having two completely separate
> > paths for the initrd is completely unmaintainable for the long-term.  I
> > think that I'd rather cut the busybox down to just the minimal set of
> > tools needed and then still use nash as the base shell.  And actually,
> > getting it so that we're using the main busybox instead of
> > busybox-initrd would be nice (I need to look at the anaconda specific
> > config differences so that I can try to merge those to not require a
> > weird subpackage).  This would be especially as there are a few
> > "features" in nash that aren't going to be in a standard shell (things
> > like handling of quiet mode, the simple mkdmnod present, etc)
> This is a test package. I patched mkinitrd to use busybox for udev support
> only, the non-udev version is the working fallback for the user.
>
> nash is not needed anymore with busybox::ash and busybox::linuxrc. Why using 
> and maintaining an own tool if there is nearly the same in busybox, already?

The question is whether it makes more sense to use busybox globally when
there are things that are needed that it's not going to have (having the
setquiet thing in busybox would seem bizarre as well as a few other
things).  If we're going to go to using busybox, then it has to be done
across the board.  Two different paths is a complete non-starter.
> > > start udev, use udevsend as hotplug
> > > load modules (eg. controller, filesystem)
> > > umount /sys
> > > locate root device
> >
> > I don't like this at all.  For one thing, doesn't it currently break
> > with root=LABEL=/?  Is there a reason not to just use /dev/root here as
> > we currently do?
> /dev/root might be nice to look at, but it is not necessary and transparent at 
> all. The real boot device is available and can be used directly. LABEL=X is 
> also supported in the busybox::mount test version.

I guess I'm just not seeing how it's not transparent.  /dev/root
corresponds to whatever you passed as root=.  That translation happens
without massive amounts of magic, especially with the sysfs parsing bits
that are there now.

Jeremy

[Owen Taylor]

On Fri, 2004-05-28 at 18:05, Thomas Woerner wrote:
> There are test packages in http://people.redhat.com/twoerner/UDEV/ for using 
> udev in initrd with persistent devices.

I just wanted to revisit this and ask how this work was going?

I really have no technical opinions on how it should be implemented
in detail, but I think it's pretty important to get default use of
udev(*) into FC3 ... not just for dynamic device usage, HAL, etc,
but in order to make read-only root setups (e.g., LTSP style network
boot) easier.

Regards,
    					Owen

(*) I know some people (yes, you, Jeremy) have serious reservations
    about the details of how udev is implemented. And I really
    just mean "dynamic creation of device nodes on a ram filesystem".
    But I don't think the fact that udev is too 
    bloated/complex/policyless/whatever to run in Anaconda should keep
    us from trying to start fixing these problems for installed
    systems.

[Florian La Roche]

On Mon, Jul 05, 2004 at 11:44:51AM +0200, Owen Taylor wrote:
> On Fri, 2004-05-28 at 18:05, Thomas Woerner wrote:
> > There are test packages in http://people.redhat.com/twoerner/UDEV/ for using 
> > udev in initrd with persistent devices.
>
> I just wanted to revisit this and ask how this work was going?
>
> I really have no technical opinions on how it should be implemented
> in detail, but I think it's pretty important to get default use of
> udev(*) into FC3 ... not just for dynamic device usage, HAL, etc,
> but in order to make read-only root setups (e.g., LTSP style network
> boot) easier.
>
> Regards,
>    					Owen
>
> (*) I know some people (yes, you, Jeremy) have serious reservations
>     about the details of how udev is implemented. And I really
>     just mean "dynamic creation of device nodes on a ram filesystem".
>     But I don't think the fact that udev is too 
>     bloated/complex/policyless/whatever to run in Anaconda should keep
>     us from trying to start fixing these problems for installed
>     systems.

If HAL is also a daemon, then it could also provide the same functionality
as udev? Or could dbus-support be added to udev, too?

I also haven't looked at this myself, but AFAIK udev is collecting the
information to maintain /dev and hal is a daemon providing information
on available hardware. Hmmm...

greetings,

Florian La Roche

[David Zeuthen]

On Mon, 2004-07-05 at 18:32 +0200, Florian La Roche wrote:
> > (*) I know some people (yes, you, Jeremy) have serious reservations
> >     about the details of how udev is implemented. And I really
> >     just mean "dynamic creation of device nodes on a ram filesystem".
> >     But I don't think the fact that udev is too 
> >     bloated/complex/policyless/whatever to run in Anaconda should keep
> >     us from trying to start fixing these problems for installed
> >     systems.
>
> If HAL is also a daemon, then it could also provide the same functionality
> as udev? Or could dbus-support be added to udev, too?

udev is not a daemon; it does contain udevd that can optionally be used
to serialise the hotplug events etc., but udev can also be run instead
of /sbin/hotplug.

And when you build with klibc, then udev is very small.
> I also haven't looked at this myself, but AFAIK udev is collecting the
> information to maintain /dev and hal is a daemon providing information
> on available hardware. Hmmm...

HAL and udev solves two completely different problems.

It's true, yes, that HAL uses udev to name device nodes using the /etc/
dev.d callouts (to send a message to the HAL daemon through the system
message bus (D-BUS) using the hal.dev program), but that's about it.

We could do device node naming and creation in HAL[1] but udev already
exists and works very well. And you want to use udev for installations
where a desktop isn't required because then you probably wouldn't like
to have HAL installed.

I hope this clarifies.

Thanks,
David

[1] : And if fact, one of the fundamental ideas about HAL is that
(desktop) applications should never care about device nodes, they are
merely cookies obtained when the (desktop) application queries the HAL
daemon for devices of a certain type.

[Greg KH]

On Mon, Jul 05, 2004 at 11:44:51AM +0200, Owen Taylor wrote:
> (*) I know some people (yes, you, Jeremy) have serious reservations
>     about the details of how udev is implemented. And I really
>     just mean "dynamic creation of device nodes on a ram filesystem".
>     But I don't think the fact that udev is too 
>     bloated/complex/policyless/whatever to run in Anaconda should keep
>     us from trying to start fixing these problems for installed
>     systems.

Um, I have never heard of such objections before.  If _anyone_ has _any_
questions/issue/objections/rants about the implementation of udev, or
any other kind of complaints about udev, please let me, and the
linux-hotplug-devel mailing list know.  Without us knowing, nothing will
change :)

thanks,

greg k-h

[Jeremy Katz]

On Mon, 2004-07-05 at 13:17 -0700, Greg KH wrote:
> On Mon, Jul 05, 2004 at 11:44:51AM +0200, Owen Taylor wrote:
> > (*) I know some people (yes, you, Jeremy) have serious reservations
> >     about the details of how udev is implemented. And I really
> >     just mean "dynamic creation of device nodes on a ram filesystem".
> >     But I don't think the fact that udev is too 
> >     bloated/complex/policyless/whatever to run in Anaconda should keep
> >     us from trying to start fixing these problems for installed
> >     systems.
>
> Um, I have never heard of such objections before.  If _anyone_ has _any_
> questions/issue/objections/rants about the implementation of udev, or
> any other kind of complaints about udev, please let me, and the
> linux-hotplug-devel mailing list know.  Without us knowing, nothing will
> change :)

I've replied with such to _every_ request/question about udev here.  I'm
working on writing up something more complete to send, but 24 hour days
plus a variety of Life things to deal with have kept me from having the
time to actually get it done.  Things should settle down for me later
this week and I'll manage to get it written up.  The short and simple
version is that by not having any policy dictated, the system becomes
overly complicated and difficult to deal with.

Jeremy

[Jeremy Katz]

On Mon, 2004-07-05 at 11:44 +0200, Owen Taylor wrote:
> (*) I know some people (yes, you, Jeremy) have serious reservations
>     about the details of how udev is implemented. And I really
>     just mean "dynamic creation of device nodes on a ram filesystem".
>     But I don't think the fact that udev is too 
>     bloated/complex/policyless/whatever to run in Anaconda should keep
>     us from trying to start fixing these problems for installed
>     systems.

It's not anaconda that worries me the most.  If we're not doing any sort
of different device naming, then with my anaconda hat on, I'll just
stick my fingers in my ears and pretend it doesn't exist.  "Dynamic
creation of device nodes on a ram filesystem" actually already happens
in anaconda, so it's not like it's a foreign concept or something that
I'm completely against.  I have my doubts as to the value of it on a
general purpose system, but in your weird diskless case, sure, it makes
sense.  Granted, I can implement it as something far simpler than udev.

My bigger concern is that udev has _zero_ policy.  It basically is a
"well, we want to let people do what they want" system.  Which is no
better than doing nothing at all.  And then, when you try to put it into
initrds, you have to allow the full range of shell utilities which is
just absurdity.  If we're willing to say "this is our policy, if you
change it, you get to make changes to other things too so that they keep
working", that's fine and then udev could be almost reasonable (although
I still think it's overkill)

Jeremy

[Owen Taylor]

On Tue, 2004-07-06 at 22:28, Jeremy Katz wrote:
> On Mon, 2004-07-05 at 11:44 +0200, Owen Taylor wrote:
> > (*) I know some people (yes, you, Jeremy) have serious reservations
> >     about the details of how udev is implemented. And I really
> >     just mean "dynamic creation of device nodes on a ram filesystem".
> >     But I don't think the fact that udev is too 
> >     bloated/complex/policyless/whatever to run in Anaconda should keep
> >     us from trying to start fixing these problems for installed
> >     systems.
>
> It's not anaconda that worries me the most.  If we're not doing any sort
> of different device naming, then with my anaconda hat on, I'll just
> stick my fingers in my ears and pretend it doesn't exist.  "Dynamic
> creation of device nodes on a ram filesystem" actually already happens
> in anaconda, so it's not like it's a foreign concept or something that
> I'm completely against.  I have my doubts as to the value of it on a
> general purpose system, but in your weird diskless case, sure, it makes
> sense.  Granted, I can implement it as something far simpler than udev.

The value of it on the case of the writable root filesystem is that
you only have one path for how the system works, not two. Changes
to device naming only have to be put into one place. Eventually we
can simple drop the dev package and it's 18,000 files.

The less we have to modify the root file-system in our normal
configuration, the less "weird" the diskless case is.

Plus we can't get away from the fact that /dev really is a dynamic
system. Even if we ignore hotplug, we are modifying the permissions
on it for the console user stuff. As such writing these changes to
disk across reboots is wrong.
> My bigger concern is that udev has _zero_ policy.  It basically is a
> "well, we want to let people do what they want" system.  Which is no
> better than doing nothing at all.  And then, when you try to put it into
> initrds, you have to allow the full range of shell utilities which is
> just absurdity.  If we're willing to say "this is our policy, if you
> change it, you get to make changes to other things too so that they keep
> working", that's fine and then udev could be almost reasonable (although
> I still think it's overkill)

There's a lot of other components of our system which are absurdly
over-configurable in ways that would badly break the system - the
X init scripts, the init scripts, gdm, etc, etc. Isn't turning
over-configurability into a working system one of the main 
OS-assembly tasks?

Clearly there has to be a policy about how devices are named; it's
just one of the things that has to be there for a stable usable
system. Having a simple C program that can read a policy 
description file and name devices would certainly be vastly more
efficient way of doing things than all the shell scripts that 
udev runs.

But udev exists now, and that's a big advantage for it.

Regards,
    	    			    Owen

[Jeremy Katz]

On Tue, 2004-07-06 at 18:17 +0200, Owen Taylor wrote:
> On Tue, 2004-07-06 at 22:28, Jeremy Katz wrote:
> The value of it on the case of the writable root filesystem is that
> you only have one path for how the system works, not two. Changes
> to device naming only have to be put into one place. Eventually we
> can simple drop the dev package and it's 18,000 files.

But exactly what does the 18k files cost it?  Similarly, we could drop
ldconfig runs in %post and just have all of the symlinks created on each
boot, but that doesn't strike me as a good idea either.  It's a useful
optimization to have them laid down by the install because then you
never have to create new device nodes.  Which can be a lot of device
nodes per device.  Changes to device naming is simple -- just make what
gets used for the creation the same as what gets used in the dev
package's spec file.  Nice and simple to do with current infrastructure.
> The less we have to modify the root file-system in our normal
> configuration, the less "weird" the diskless case is.

One tweak in /etc/sysconfig/foo doesn't seem overkill -- it could even
be something that's used for more than one thing (as I'm fairly certain
there will have to be other things that happen slightly different in the
diskless case)
> Plus we can't get away from the fact that /dev really is a dynamic
> system. Even if we ignore hotplug, we are modifying the permissions
> on it for the console user stuff. As such writing these changes to
> disk across reboots is wrong.

I disagree.  We'll just agree to disagree here.
> > My bigger concern is that udev has _zero_ policy.  It basically is a
> > "well, we want to let people do what they want" system.  Which is no
> > better than doing nothing at all.  And then, when you try to put it into
> > initrds, you have to allow the full range of shell utilities which is
> > just absurdity.  If we're willing to say "this is our policy, if you
> > change it, you get to make changes to other things too so that they keep
> > working", that's fine and then udev could be almost reasonable (although
> > I still think it's overkill)
>
> There's a lot of other components of our system which are absurdly
> over-configurable in ways that would badly break the system - the
> X init scripts, the init scripts, gdm, etc, etc. Isn't turning
> over-configurability into a working system one of the main 
> OS-assembly tasks?

Yes, but does that mean that we should add more overly configurable bits
when something far simpler would suffice?
> Clearly there has to be a policy about how devices are named; it's
> just one of the things that has to be there for a stable usable
> system. Having a simple C program that can read a policy 
> description file and name devices would certainly be vastly more
> efficient way of doing things than all the shell scripts that 
> udev runs.

Except that with what udev currently allows, you can't do so with one C
program...  because everyone wants a different way to do it.
> But udev exists now, and that's a big advantage for it.

Existence doesn't necessarily make something the best solution to a
problem.  In cases with significant architectural impact on the system,
it's far better to take a little bit longer and get a better technical
solution than to throw in something just because it's there.  I'll just
point to the file choose in gtk as an example here :-)

Jeremy

[David Zeuthen]

On Tue, 2004-07-06 at 18:38 -0400, Jeremy Katz wrote:
> On Tue, 2004-07-06 at 18:17 +0200, Owen Taylor wrote:
> > On Tue, 2004-07-06 at 22:28, Jeremy Katz wrote:
> > The value of it on the case of the writable root filesystem is that
> > you only have one path for how the system works, not two. Changes
> > to device naming only have to be put into one place. Eventually we
> > can simple drop the dev package and it's 18,000 files.
>
> But exactly what does the 18k files cost it?  Similarly, we could drop
> ldconfig runs in %post and just have all of the symlinks created on each
> boot, but that doesn't strike me as a good idea either.  It's a useful
> optimization to have them laid down by the install because then you
> never have to create new device nodes.  Which can be a lot of device
> nodes per device.  Changes to device naming is simple -- just make what
> gets used for the creation the same as what gets used in the dev
> package's spec file.  Nice and simple to do with current infrastructure.

One very useful feature that is not readily available in current
infrastructure is that udev maintains a database. This allows reverse
lookup into sysfs, e.g. given device node /dev/sda you can very easily
determine what physical device this device node corresponds to. And you
can also go the other way [1].

With the infrastructure available today (e.g. static dev), you'd have to
search either for the right major:minor in /dev or find the right 'dev'
file in sysfs which would be insanely expensive.
> > > My bigger concern is that udev has _zero_ policy.  It basically is a
> > > "well, we want to let people do what they want" system.  Which is no
> > > better than doing nothing at all.

Which may actually be good in a way as it discourages developers to
assume that e.g. /dev/cdrom is the (default) optical drive, /dev/dsp is
the (default) audio device etc. Heh, so to fully test it we'd just
select a new naming scheme on every reboot :-)

But, yeah, you're right, there's so many legacy applications out there
that relies on device node naming policies, and I do understand that
this is not necessarily bad. Though it would be nice they did the right
thing, at least for desktop applications.

Cheers,
David

[1] :

[david@ixus david]$ udevinfo -q path -n /dev/sda
/block/sda
[david@ixus david]$ ls -l /sys/block/sda/device
lrwxrwxrwx  1 root root 0 Jul  6 19:17 /sys/block/sda/device -> ../../
devices/pci0000:00/0000:00:10.0/0000:02:07.2/usb1/1-1/1-1.2/1-1.2:1.0/
host9/9:0:0:0

[david@ixus david]$ udevinfo -r -q name -p /sys/block/sda
/dev/sda

[Florian La Roche]

> But exactly what does the 18k files cost it?  Similarly, we could drop
> ldconfig runs in %post and just have all of the symlinks created on each
> boot, but that doesn't strike me as a good idea either.  It's a useful
> optimization to have them laid down by the install because then you
> never have to create new device nodes.  Which can be a lot of device
> nodes per device.  Changes to device naming is simple -- just make what
> gets used for the creation the same as what gets used in the dev
> package's spec file.  Nice and simple to do with current infrastructure.

I think we will have to provide more flexibility here. I personally
also like to populate /dev at install time and then don't worry about
scanning devices on each boot and I personally still don't use devices
I attach at runtime to my systems. I think I would also disable udev
on startup for my machines the same way I disable kudzu now and some
other scripts on bootup I don't need.

I still think this is useful to other people. udev has been tested against
pam, selinux and provides this greater flexibility. The comments here have
been right. E.g. there is no reason the list of devices within the
udev database should not be synchronized against our static makedev package
and many other changes probably also make sense.
In my opinion this means further integration of udev is needed, not keeping
it away. Incrementally adding to udev is way better than trying to come
up with a new way to solve the same things.
> > Plus we can't get away from the fact that /dev really is a dynamic
> > system. Even if we ignore hotplug, we are modifying the permissions
> > on it for the console user stuff. As such writing these changes to
> > disk across reboots is wrong.
>
> I disagree.  We'll just agree to disagree here.

And I think people are right if they want to have machines running without
udev, but also see that for other setups it will be needed.
I'd argue that way more testing is needed until we know for sure that
a tmpfs on bootup is working fine, but I don't see a reason to stop further
development in that direction and thus further integration of udev.
> Yes, but does that mean that we should add more overly configurable bits
> when something far simpler would suffice?

Couldn't you add to udev to make it simpler again?
> Except that with what udev currently allows, you can't do so with one C
> program...  because everyone wants a different way to do it.

It's gonna be needed in the future. (Blinking, colored, flashing devices
and my daughter will love them... ;-)
> Existence doesn't necessarily make something the best solution to a
> problem.  In cases with significant architectural impact on the system,
> it's far better to take a little bit longer and get a better technical
> solution than to throw in something just because it's there.  I'll just
> point to the file choose in gtk as an example here :-)

You have valid points. udev is still under more active development and
I hope some of the concerns are picked up and resolved in newer releases.
gtk is also not dying due to revamped additions of a file chooser, even
if many apps might suffer from the first version of it or have written
their own implementation of it.

greetings,

Florian La Roche

[Greg KH]

On Wed, Jul 07, 2004 at 09:46:23AM +0200, Florian La Roche wrote:
> You have valid points. udev is still under more active development and
> I hope some of the concerns are picked up and resolved in newer releases.

Actully udev development has slowed down, and has been pretty much
reduced to tweaking the base rules and permissions and adding new plugin
programs that udev can call if you want it to (to get a label off of any
fs, get scsi id information, etc.)

Also the early boot issue is getting worked on (lvm startup is pretty
nasty, we need to name devices in a specific order for dm to work
correctly it seems.)

But I don't see anything lacking in the current udev package, and don't
see any concrete suggestions in this thread either (people seem to not
realize that udev _is_ a tiny C program...)  But am very open to any
proposals that anyone might have (if they do have them, please cc the
linux-hotplug-devel mailing list where the other udev developers are.)

thanks,

greg k-h

[Owen Taylor]

On Wed, 2004-07-07 at 00:38, Jeremy Katz wrote:
> On Tue, 2004-07-06 at 18:17 +0200, Owen Taylor wrote:
> > On Tue, 2004-07-06 at 22:28, Jeremy Katz wrote:
> > The value of it on the case of the writable root filesystem is that
> > you only have one path for how the system works, not two. Changes
> > to device naming only have to be put into one place. Eventually we
> > can simple drop the dev package and it's 18,000 files.
>
> But exactly what does the 18k files cost it?  Similarly, we could drop
> ldconfig runs in %post and just have all of the symlinks created on each
> boot, but that doesn't strike me as a good idea either.  It's a useful
> optimization to have them laid down by the install because then you
> never have to create new device nodes.  Which can be a lot of device
> nodes per device.

How much of an optimization though? Creating several hundred device
nodes on a ram filesystem is going to take a tiny fraction of a
second. I admit the 18,000 files don't matter much either (unless
you are continually installing in which case it's 20 seconds an
install...)
> Changes to device naming is simple -- just make what
> gets used for the creation the same as what gets used in the dev
> package's spec file.  Nice and simple to do with current infrastructure.

If that's to have a single configuration file used both by MAKEDEV and
udev; sure that's another workable solution. But are we doing anything
to get there?
> > The less we have to modify the root file-system in our normal
> > configuration, the less "weird" the diskless case is.
>
> One tweak in /etc/sysconfig/foo doesn't seem overkill -- it could even
> be something that's used for more than one thing (as I'm fairly certain
> there will have to be other things that happen slightly different in the
> diskless case)

I'm not talking about how many things have to be changed in the
system image, I'm talking about how many possibilities there are for
bugs to be present in one setup and not in the other.
> > Plus we can't get away from the fact that /dev really is a dynamic
> > system. Even if we ignore hotplug, we are modifying the permissions
> > on it for the console user stuff. As such writing these changes to
> > disk across reboots is wrong.
>
> I disagree.  We'll just agree to disagree here.

On the philosophical questions, sure we can agree to disagree. But
I'm really concerned that there has been an "agreement to disagree"
on a technical level. Parts of the system are beginning to require
at least a partially dynamic /dev, and the maintainers of those areas
are assuming udev. But in other areas, we seem to be dragging our feet
and saying that doesn't work.

The reason I'm pushing for going to a fully dynamic /dev always is
that forces the issue. Dynamic /dev is forced to really work, not
just be some checklist item which works in a few test configurations.

It also (in my opinion) simplifies the system. Getting hardware to 
"just work" seems hard enough to do with one configuration path that I
can't really see why people want to have *two* configurations.

But, yes, there other ways that would work. But if we are going to
do it some other way, where's the roadmap for that? Where's the
explanation of how we *are* going to do it?
> > > My bigger concern is that udev has _zero_ policy.  It basically is a
> > > "well, we want to let people do what they want" system.  Which is no
> > > better than doing nothing at all.  And then, when you try to put it into
> > > initrds, you have to allow the full range of shell utilities which is
> > > just absurdity.  If we're willing to say "this is our policy, if you
> > > change it, you get to make changes to other things too so that they keep
> > > working", that's fine and then udev could be almost reasonable (although
> > > I still think it's overkill)
> >
> > There's a lot of other components of our system which are absurdly
> > over-configurable in ways that would badly break the system - the
> > X init scripts, the init scripts, gdm, etc, etc. Isn't turning
> > over-configurability into a working system one of the main 
> > OS-assembly tasks?
>
> Yes, but does that mean that we should add more overly configurable bits
> when something far simpler would suffice?

As Alan said, it's an implementation issue. What we need to implement
is a device naming policy, and a mechanism for implementing that
policy at package-build-time/boot-time/hotplug-time/whatever.

If that mechanism involves udev and a bunch of shell scripts, that
may be a very inefficient way of implementing the policy, but, it's
not introducing over-configurability into the system. What's 
configurability for the udev maintainers is not configurability for
our end users.
> > Clearly there has to be a policy about how devices are named; it's
> > just one of the things that has to be there for a stable usable
> > system. Having a simple C program that can read a policy 
> > description file and name devices would certainly be vastly more
> > efficient way of doing things than all the shell scripts that 
> > udev runs.
>
> Except that with what udev currently allows, you can't do so with one C
> program...  because everyone wants a different way to do it.

Any finite set of device naming schemes can be implemented in a 
C program. And even something quite complex like naming by path
to the device isn't going to be a lot of code.

But really, I'm not sure I follow your train of logic. The fact that
udev allows implementing arbitrary crack-rock device naming schemes
doesn't imply to me that if we go with a solution based on udev
now we'd then have to allow implementing arbitrary crack-rock
device naming schemes forever after.
> > But udev exists now, and that's a big advantage for it.
>
> Existence doesn't necessarily make something the best solution to a
> problem.  In cases with significant architectural impact on the system,
> it's far better to take a little bit longer and get a better technical
> solution than to throw in something just because it's there.  I'll just
> point to the file choose in gtk as an example here :-)

Where's the equivalent to:

http://people.redhat.com/otaylor/fosdem2003/file-selector.html

Then?

Owen

[Bill Nottingham]

Owen Taylor ([e-mail]) said:
> The value of it on the case of the writable root filesystem is that
> you only have one path for how the system works, not two. Changes
> to device naming only have to be put into one place. Eventually we
> can simple drop the dev package and it's 18,000 files.

The issue here is that it's not *that* simple, once you
start handling all the devices that aren't in sysfs. Moreover,
it breaks the 'load module on device access' model.

Going to a fully dynamic /dev is a paradigm shift, even if you
keep the same device naming model.
> There's a lot of other components of our system which are absurdly
> over-configurable in ways that would badly break the system - the
> X init scripts, the init scripts, gdm, etc, etc. Isn't turning
> over-configurability into a working system one of the main 
> OS-assembly tasks?

Yes, but the raison d'etre of the initscripts or gdm aren't
really 'infinite configurability to whatever policy you want'.
Yet it's a design goal of udev, or at least, it appears to be.

Bill

[Florian La Roche]

> The issue here is that it's not *that* simple, once you
> start handling all the devices that aren't in sysfs. Moreover,
> it breaks the 'load module on device access' model.

I thought this is more the exception and such devices should go into
a list of always available devices.

greetings,

Florian La Roche

[Bill Nottingham]

Florian La Roche ([e-mail]) said:
> > The issue here is that it's not *that* simple, once you
> > start handling all the devices that aren't in sysfs. Moreover,
> > it breaks the 'load module on device access' model.
>
> I thought this is more the exception and such devices should go into
> a list of always available devices.

It's not really the exception; it's the impetus behind kmod and
module aliases in general.

Bill

[Greg KH]

On Tue, Jul 06, 2004 at 06:50:36PM -0400, Bill Nottingham wrote:
> Owen Taylor ([e-mail]) said:
> > The value of it on the case of the writable root filesystem is that
> > you only have one path for how the system works, not two. Changes
> > to device naming only have to be put into one place. Eventually we
> > can simple drop the dev package and it's 18,000 files.
>
> The issue here is that it's not *that* simple, once you
> start handling all the devices that aren't in sysfs. Moreover,
> it breaks the 'load module on device access' model.

We've been breaking that in the kernel for years now (look at the shared
major numbers for the USB core as an example).  And we have stated that
this will continue in the future, as we have shifted to a "load module
on device detection" model.
> Going to a fully dynamic /dev is a paradigm shift, even if you
> keep the same device naming model.

It shouldn't have to be.  The default udev naming rules are dirt simple,
with no script callouts and work for the LANNANA device model today.

thanks,

greg k-h

[Bill Nottingham]

Greg KH ([e-mail]) said:
> > The issue here is that it's not *that* simple, once you
> > start handling all the devices that aren't in sysfs. Moreover,
> > it breaks the 'load module on device access' model.
>
> We've been breaking that in the kernel for years now (look at the shared
> major numbers for the USB core as an example).  And we have stated that
> this will continue in the future, as we have shifted to a "load module
> on device detection" model.

Yes, but it still mostly works now. Otherwise, there wouldn't be
all those MODULE_ALIAS entries in the kernel source code. *ducks*

Bill

[Alan Cox]

On Tue, Jul 06, 2004 at 06:17:07PM +0200, Owen Taylor wrote:
> Clearly there has to be a policy about how devices are named; it's
> just one of the things that has to be there for a stable usable
> system. Having a simple C program that can read a policy 
> description file and name devices would certainly be vastly more
> efficient way of doing things than all the shell scripts that 
> udev runs.
>
> But udev exists now, and that's a big advantage for it.

Rewriting udev in C is practical, that implies the concept is right but
the implementation can be optimised. That puts it in the same class as
openoffice, gnome and most of our config tools so I don't see it as a 
barrier. What has to be right is the interface

[Nicolas Mailhot]

Le mar, 06/07/2004 à 18:17 +0200, Owen Taylor a écrit :
> There's a lot of other components of our system which are absurdly
> over-configurable in ways that would badly break the system - the
> X init scripts, the init scripts, gdm, etc, etc.

ROTFL

Have you ever tried to configure gdm on a RedHat/Fedora system?

I happen to live in a country that uses the 24h format, so I tried
(doesn't seem like over-configurability, right, asking to display the
time in a format one is used to pars?e)

*EVERY* single time gdm is updated the clock format is reseted. You have
to keep re-telling GDM to use your format. After ~ 2 years of trying to
keep up with the system I've basically given up (and try not to look at
the clock because I know it'll make me mad any day).

So don't worry - gdm over-configurability has largely been squashed by
the package maintainers.

[Greg KH]

On Tue, Jul 06, 2004 at 06:17:07PM +0200, Owen Taylor wrote:
> > "well, we want to let people do what they want" system.  Which is no
> > better than doing nothing at all.  And then, when you try to put it into
> > initrds, you have to allow the full range of shell utilities which is
> > just absurdity.  If we're willing to say "this is our policy, if you
> > change it, you get to make changes to other things too so that they keep
> > working", that's fine and then udev could be almost reasonable (although
> > I still think it's overkill)
>
> There's a lot of other components of our system which are absurdly
> over-configurable in ways that would badly break the system - the
> X init scripts, the init scripts, gdm, etc, etc. Isn't turning
> over-configurability into a working system one of the main 
> OS-assembly tasks?
>
> Clearly there has to be a policy about how devices are named; it's
> just one of the things that has to be there for a stable usable
> system. Having a simple C program that can read a policy 
> description file and name devices would certainly be vastly more
> efficient way of doing things than all the shell scripts that 
> udev runs.

Um, udev is a "simple C program that reads a policy description file and
names devices".  It doesn't execute any shell scripts, unless you want
it too (like the current package in the Debian tree, what horrors...)

Compiled against klibc, udev ends up at 58Kb, static.  That's only 4
times bigger than /bin/true (which is dynamically linked against glibc
too...)  /bin/cp is bigger than that (again, dynamically linked...)

Look at the default udev rules that it ships with.  No shell scripts.
No complex rules.  And that gives you the sane device naming policy that
Red Hat uses today.

Yes, you can use udev to call fancy shell scripts if you want to (to
emulate the devfs naming rules, you pretty much have to), but that's
what makes udev powerful, and an answer to pretty much all users.
There's no reason Red Hat has to ship udev using a complex rule set full
of shell scripts.
> But udev exists now, and that's a big advantage for it.

Yes, and as it seems to fit your description, that's an even bigger
advantage :)

thanks,

greg k-h

[Owen Taylor]

On Thu, 2004-07-08 at 04:11, Greg KH wrote:
> On Tue, Jul 06, 2004 at 06:17:07PM +0200, Owen Taylor wrote:
> > > "well, we want to let people do what they want" system.  Which is no
> > > better than doing nothing at all.  And then, when you try to put it into
> > > initrds, you have to allow the full range of shell utilities which is
> > > just absurdity.  If we're willing to say "this is our policy, if you
> > > change it, you get to make changes to other things too so that they keep
> > > working", that's fine and then udev could be almost reasonable (although
> > > I still think it's overkill)
> >
> > There's a lot of other components of our system which are absurdly
> > over-configurable in ways that would badly break the system - the
> > X init scripts, the init scripts, gdm, etc, etc. Isn't turning
> > over-configurability into a working system one of the main 
> > OS-assembly tasks?
> >
> > Clearly there has to be a policy about how devices are named; it's
> > just one of the things that has to be there for a stable usable
> > system. Having a simple C program that can read a policy 
> > description file and name devices would certainly be vastly more
> > efficient way of doing things than all the shell scripts that 
> > udev runs.
>
> Um, udev is a "simple C program that reads a policy description file and
> names devices".  It doesn't execute any shell scripts, unless you want
> it too (like the current package in the Debian tree, what horrors...)
>
> Compiled against klibc, udev ends up at 58Kb, static.  That's only 4
> times bigger than /bin/true (which is dynamically linked against glibc
> too...)  /bin/cp is bigger than that (again, dynamically linked...)
>
> Look at the default udev rules that it ships with.  No shell scripts.
> No complex rules.  And that gives you the sane device naming policy that
> Red Hat uses today.
>
> Yes, you can use udev to call fancy shell scripts if you want to (to
> emulate the devfs naming rules, you pretty much have to), but that's
> what makes udev powerful, and an answer to pretty much all users.
> There's no reason Red Hat has to ship udev using a complex rule set full
> of shell scripts.

For some reason the udev package we have in rawhide now:

http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/ud...

Seems to fall into the category of "complex rule set full of shell
scripts" ... in some testing I was doing a while ago, an initial
run of udev to populate /dev was executing ~3000 processes.

If you have time to take a look at that configuration of udev, I'd be
interested to know whether you think it's:

- Just poor configuration of udev to achieve something that could
   be done much more simply and efficiently.

- A policy that "pretty much requires" shell scripts. (Not that I can
   imagine what fixed policy is easier to implement as a rats nest
   of shell scripts...)

Thanks,
    					Owen

[Harald Hoyer]

Owen Taylor wrote:
> For some reason the udev package we have in rawhide now:
>
> http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/ud...
>
> Seems to fall into the category of "complex rule set full of shell
> scripts" ... in some testing I was doing a while ago, an initial
> run of udev to populate /dev was executing ~3000 processes.
>
> If you have time to take a look at that configuration of udev, I'd be
> interested to know whether you think it's:
>
> Just poor configuration of udev to achieve something that could
> be done much more simply and efficiently.
>
> A policy that "pretty much requires" shell scripts. (Not that I can
> imagine what fixed policy is easier to implement as a rats nest
> of shell scripts...)
>
> Thanks,
>    					Owen

just install the udev rpm and not the udev-persistent rpm and you have a simple setup

[Owen Taylor]

On Thu, 2004-07-08 at 11:45, Harald Hoyer wrote:
> just install the udev rpm and not the udev-persistent rpm and you have a simple setup

This raises a whole slew of issues in my mind; among them:

- How would the user know if they should install udev-persistant or
   not? Is there a one-sentence answer? [1] Should it be part of the
   default install?

- Isn't having installing packages changes behavior something
   we want to avoid? Or does udev-persistant just add *more* device
   names.

- Could the udev-persistant stuff be made efficient as well? What
   additions to udev would be needed for that?

Regards,
    					Owen

[1] The package description is:

udev-persistent enables persistent device naming with udev

That's not the answer I'm looking for :-)

[Alexander Larsson]

On Thu, 2004-07-08 at 19:32, Owen Taylor wrote:
> On Thu, 2004-07-08 at 11:45, Harald Hoyer wrote:
> > just install the udev rpm and not the udev-persistent rpm and you have a simple setup
>
> This raises a whole slew of issues in my mind; among them:
> How would the user know if they should install udev-persistant or
> not? Is there a one-sentence answer? [1] Should it be part of the
> default install?

Its gonna make everything installs force you to use udev-persistant too.
I don't think that is right.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   [e-mail]    [e-mail] 
He's a maverick Amish dog-catcher plagued by the memory of his family's brutal 
murder. She's a hard-bitten gold-digging former first lady with the power to 
see death. They fight crime!

[Thomas Woerner]

There are new FC3 test packages for udev usage in initrd:

http://people.redhat.com/twoerner/UDEV/FC3/

This is a minimal version without udev-persistent support and no busybox. It is using 
the normal nash initrd environment.

U S A G E
=========

- Install initscripts, mkinitrd and udev updates
- To use udev in initrd, set USE_UDEV and UDEV_INITRD in /etc/sysconfig/udev.
   udev will then use the normal /dev directory and will generate devices in there.
- udev can be started in a clean mounted ramfs on /dev by setting UDEV_RAMFS
- To get this ramfs /dev to your system, set UDEV_KEEP_DEV. Setting UDEV_KEEP_DEV
   also sets UDEV_RAMFS. /dev will be bind-mounted to your root directory, then.
   - Unset udev_owner in /etc/udev/udev.conf to get normal persimissions. Newer udev
     packages are not setting device ownerships or permissions, if the device already
     exists. But this is needed if you are keeping your /dev, because udev will
     generate devices with root ownership (there is no other user in initrd) and
     udevstart in rc.sysinit will not set correct permissions, then.
- Setting udev_remove will remove devices if the corresponding hardware device is
   gone e.g. for USB devices.

E X A M P L E   C O N F I G U R A T I O N
=========================================

/etc/sysconfig/udev
-------------------
...
USE_UDEV="yes"
UDEV_INITRD="yes"
UDEV_RAMFS="yes"
UDEV_KEEP_DEV="yes"

/etc/udev/udev.conf
-------------------
...
udev_owner="no"
udev_remove="yes"

W A R N I N G
=============

Do not overwrite your initrd images and make new grub entries, to have a sane 
fallback. Please be careful if you are using LVM or RAID. These are not tested, yet.

Thomas

[Jeremy Katz]

So, I've sat down and spent a while looking at this and looking at udev
itself.  I still think that udev could be simpler by dictating policies
and not leaving everything up in the air for the user to decide, but I'm
tired of having that argument as it's seemingly a dead end at this
point.

On Fri, 2004-07-09 at 15:31 +0200, Thomas Woerner wrote:
> This is a minimal version without udev-persistent support and no busybox. It is using 
> the normal nash initrd environment.

This looks a lot better to me.  A couple of patches are missing on the
mkinitrd side to a) add bind mount support to nash and b) to use nash
mount properly.  Attached the patch to this mail (mkinitrd-
bindmount.patch).
> To use udev in initrd, set USE_UDEV and UDEV_INITRD in /etc/sysconfig/udev.
>  udev will then use the normal /dev directory and will generate devices in there.

If we're putting the patches in and we want udev to be the default,
let's go ahead and set it up as such.
> To get this ramfs /dev to your system, set UDEV_KEEP_DEV. Setting UDEV_KEEP_DEV
>  also sets UDEV_RAMFS. /dev will be bind-mounted to your root directory, then.
> Unset udev_owner in /etc/udev/udev.conf to get normal persimissions. Newer udev
> packages are not setting device ownerships or permissions, if the device already
> exists. But this is needed if you are keeping your /dev, because udev will
> generate devices with root ownership (there is no other user in initrd) and
> udevstart in rc.sysinit will not set correct permissions, then.

The same is true with these.

Further improvements/enhancements that I think are really needed to make
this more robust and more integrated.

* Having all of the udev scripts getting copied as part of the mkinitrd
seems like it has a probability of causing spurious warnings/failures.
Luckily, this isn't needed and we can just do the next bit (which I'd
still like to lose, but could live with)
* Changing the mkinitrd copying to just copy /etc/udev/udev.conf seems
to work, but I'd really like to avoid that copy if we can.  Can we have
udev default to our defaults so that we're a bit more robust (and then I
can avoid copying the config file).  Also, this could help avoid some
strange user experiences if the file disappears for whatever reason.
* I think that leaving the standard device creation for the /dev of the
initrd even if using udev is probably not completely crazy.  Then, if
udev fails for some reason, you might still have a chance of things
working.  We could add a simple testCommand to nash and then only do
this if some obvious, always created dev node from udev didn't get
created if we want to avoid doing it always (/dev/ram0 springs to mind
since if you're in an initrd, you obviously have to have ramdisk
support)
* Why is the creation of /dev/fd, /dev/stdin, /dev/stdout, /dev/kcore,
etc duplicated between mkinitrd and start_udev?  Both run udevstart and
I don't see a real reason why we can't just have udevstart make these
links and reduce a little bit of duplication.
* The pam_console_setowner stuff really needs to just be a patch to
pam_console_apply and then use that.  Otherwise, we have a second copy
of that code to maintain and fix bugs in.  Nalin didn't seem against
this when I mentioned it to him at dinner
* Any reason why udevstart can't be done after rhgb starts to avoid text
seen before the graphical boot?
* I'd rather not use klibc if we can help it.  Mostly because
maintaining another libc strikes me as a poor idea (I want to get rid of
dietlibc :)  Ironically, both udevstart and udev are slightly smaller
when statically linked with glibc instead of klibc.
* Not really necessary, but some people might appreciate a "don't create
device nodes" option and then just keep using their static /dev.
Obviously, this would imply UDEV_INITRD=no.  Also, if we're buying into
a dynamic, this isn't going to be the default.
* The duplication between /etc/udev/udev.conf and /etc/sysconfig/udev
strikes me as a potential source of confusion.  The config files are
roughly the same syntax, let's just use one of them (and then we can
have the other be a symlink if we really feel it's necessary, but I'd
lean against not).

None of these looks particularly difficult to implement, but it's after
midnight and I'm not sure if I'll get any further before going to bed
and wanted to get this out tonight.  If no one else does, I'll probably
look at a few of them tomorrow.

There are also going to be other things that I'm sure are going to start
breaking...  I know there are places where we rely on "access device,
autoload module" working that are likely to break (sound and some
operations with loopback devices off the top of my head, probably
others).  Not sure what to do about these cases at the moment.  And I'm
completely staying away from the persistent names for right now; let's
get the simple case first and then we can go back and forth about
persistent names :)

Jeremy

[Harald Hoyer]

Jeremy Katz wrote:
> So, I've sat down and spent a while looking at this and looking at udev
> itself.  I still think that udev could be simpler by dictating policies
> and not leaving everything up in the air for the user to decide, but I'm
> tired of having that argument as it's seemingly a dead end at this
> point.

finally :)
> On Fri, 2004-07-09 at 15:31 +0200, Thomas Woerner wrote:
> > This is a minimal version without udev-persistent support and no busybox. It is using 
> > the normal nash initrd environment.
>
> This looks a lot better to me.  A couple of patches are missing on the
> mkinitrd side to a) add bind mount support to nash and b) to use nash
> mount properly.  Attached the patch to this mail (mkinitrd-
> bindmount.patch).

I think, I sent the bind patch to you months ago :)
> > To use udev in initrd, set USE_UDEV and UDEV_INITRD in /etc/sysconfig/udev.
> > udev will then use the normal /dev directory and will generate devices in there.
>
> If we're putting the patches in and we want udev to be the default,
> let's go ahead and set it up as such.

no objection
> > To get this ramfs /dev to your system, set UDEV_KEEP_DEV. Setting UDEV_KEEP_DEV
> > also sets UDEV_RAMFS. /dev will be bind-mounted to your root directory, then.
> > Unset udev_owner in /etc/udev/udev.conf to get normal persimissions. Newer udev
> > packages are not setting device ownerships or permissions, if the device already
> > exists. But this is needed if you are keeping your /dev, because udev will
> > generate devices with root ownership (there is no other user in initrd) and
> > udevstart in rc.sysinit will not set correct permissions, then.
>
> The same is true with these.
>
> Further improvements/enhancements that I think are really needed to make
> this more robust and more integrated.
> Having all of the udev scripts getting copied as part of the mkinitrd
>
> seems like it has a probability of causing spurious warnings/failures.
> Luckily, this isn't needed and we can just do the next bit (which I'd
> still like to lose, but could live with)

ok, I can live with that...
> Changing the mkinitrd copying to just copy /etc/udev/udev.conf seems
>
> to work, but I'd really like to avoid that copy if we can.  Can we have
> udev default to our defaults so that we're a bit more robust (and then I
> can avoid copying the config file).  Also, this could help avoid some
> strange user experiences if the file disappears for whatever reason.

Also ok.
> I think that leaving the standard device creation for the /dev of the
>
> initrd even if using udev is probably not completely crazy.  Then, if
> udev fails for some reason, you might still have a chance of things
> working.  We could add a simple testCommand to nash and then only do
> this if some obvious, always created dev node from udev didn't get
> created if we want to avoid doing it always (/dev/ram0 springs to mind
> since if you're in an initrd, you obviously have to have ramdisk
> support)

Hmm, ok.
> Why is the creation of /dev/fd, /dev/stdin, /dev/stdout, /dev/kcore,
>
> etc duplicated between mkinitrd and start_udev?  Both run udevstart and
> I don't see a real reason why we can't just have udevstart make these
> links and reduce a little bit of duplication.

Haven't tested it, but /sbin/init and rc.sysinit prior to start_udev may need some of these?
> The pam_console_setowner stuff really needs to just be a patch to
>
> pam_console_apply and then use that.  Otherwise, we have a second copy
> of that code to maintain and fix bugs in.  Nalin didn't seem against
> this when I mentioned it to him at dinner

would be cool!
> Any reason why udevstart can't be done after rhgb starts to avoid text
>
> seen before the graphical boot?

You may see some udev messages, if root is mounted (ro) at the time modules are loaded,
which trigger hotplug events.
> I'd rather not use klibc if we can help it.  Mostly because
>
> maintaining another libc strikes me as a poor idea (I want to get rid of
> dietlibc :)  Ironically, both udevstart and udev are slightly smaller
> when statically linked with glibc instead of klibc.

huh?
/sbin/udev.glibc.static 488096
/sbin/udev.klibc.static  58056

plus
/home/devel/harald/cvs/rpms/harald/udev/udev-029/udev-add.c:250: warning: Using
  'getgrnam' in statically linked applications requires at runtime the shared li
braries from the glibc version used for linking
udev-add.o(.text+0x5ce):/home/devel/harald/cvs/rpms/harald/udev/udev-029/udev-a
dd.c:236: warning: Using 'getpwnam' in statically linked applications requires
at runtime the shared libraries from the glibc version used for linking

ok, these could be patched out...
> Not really necessary, but some people might appreciate a "don't create
>
> device nodes" option and then just keep using their static /dev.
> Obviously, this would imply UDEV_INITRD=no.  Also, if we're buying into
> a dynamic, this isn't going to be the default.
> The duplication between /etc/udev/udev.conf and /etc/sysconfig/udev
>
> strikes me as a potential source of confusion.  The config files are
> roughly the same syntax, let's just use one of them (and then we can
> have the other be a symlink if we really feel it's necessary, but I'd
> lean against not).

Thought about that, too. Sounds ok to me, as long as /etc/udev/udev.conf
is sourceable by bash.
> None of these looks particularly difficult to implement, but it's after
> midnight and I'm not sure if I'll get any further before going to bed
> and wanted to get this out tonight.  If no one else does, I'll probably
> look at a few of them tomorrow.
>
> There are also going to be other things that I'm sure are going to start
> breaking...  I know there are places where we rely on "access device,
> autoload module" working that are likely to break (sound and some
> operations with loopback devices off the top of my head, probably
> others).  Not sure what to do about these cases at the moment.  And I'm
> completely staying away from the persistent names for right now; let's
> get the simple case first and then we can go back and forth about
> persistent names :)

cool, cool, things are moving finally! :)

[Harald Hoyer]

built udev-029-3 in dist-fc3-HEAD

[Jeremy Katz]

On Wed, 2004-07-14 at 11:33 +0200, Harald Hoyer wrote:
> Jeremy Katz wrote:
> > On Fri, 2004-07-09 at 15:31 +0200, Thomas Woerner wrote:
> > > This is a minimal version without udev-persistent support and no busybox. It is using 
> > > the normal nash initrd environment.
> >
> > This looks a lot better to me.  A couple of patches are missing on the
> > mkinitrd side to a) add bind mount support to nash and b) to use nash
> > mount properly.  Attached the patch to this mail (mkinitrd-
> > bindmount.patch).
>
> I think, I sent the bind patch to you months ago :)

Yeah, I thought I had remembered seeing something but wasn't sure.  It
wasn't in this set of patches at least, so I just quickly did it
again :)
> > Further improvements/enhancements that I think are really needed to make
> > this more robust and more integrated.
> > I think that leaving the standard device creation for the /dev of the
> >
> > initrd even if using udev is probably not completely crazy.  Then, if
> > udev fails for some reason, you might still have a chance of things
> > working.  We could add a simple testCommand to nash and then only do
> > this if some obvious, always created dev node from udev didn't get
> > created if we want to avoid doing it always (/dev/ram0 springs to mind
> > since if you're in an initrd, you obviously have to have ramdisk
> > support)
>
> Hmm, ok.

Keep in mind I'm paranoid about initrd failures and they're nearly
impossible to debug.  So as much as I can foolproof against the kernel
or some utility changing out from under me, the happier I am.  I'll go
ahead and do this piece later today.
> > Why is the creation of /dev/fd, /dev/stdin, /dev/stdout, /dev/kcore,
> >
> > etc duplicated between mkinitrd and start_udev?  Both run udevstart and
> > I don't see a real reason why we can't just have udevstart make these
> > links and reduce a little bit of duplication.
>
> Haven't tested it, but /sbin/init and rc.sysinit prior to start_udev may need some of these?

Right, but we run udevstart in the initrd, too.  So if the code to
create them is all in udevstart (and we have rc.sysinit call udevstart
instead of the start_udev wrapper), then everything should still get
created at the same times and not have any newer problems.  Or if it
can, I'm missing something entirely (not impossible)
> > The pam_console_setowner stuff really needs to just be a patch to
> >
> > pam_console_apply and then use that.  Otherwise, we have a second copy
> > of that code to maintain and fix bugs in.  Nalin didn't seem against
> > this when I mentioned it to him at dinner
>
> would be cool!

Okay -- do you want to look at this or would you rather I do so?
> > Any reason why udevstart can't be done after rhgb starts to avoid text
> >
> > seen before the graphical boot?
>
> You may see some udev messages, if root is mounted (ro) at the time modules are loaded,
> which trigger hotplug events.

Right, but for udev to be set as the hotplug handler, then it got set
from the initrd and you're using a ramfs dev.  In which case /dev is not
going to be read-only.  Do you have an example case?  And the downside
here is that it makes the rhgb details pop open instead of remaining
hidden?

It just seems a shame to be adding more messages that are going to be
potentially confusing before rhgb starts up.  It also makes it look like
something is broken since you get the console font loading ([OK]), then
welcome to fedora, then starting udev ([ok]).  The space between these
just looks and feels awkward.
> > I'd rather not use klibc if we can help it.  Mostly because
> >
> > maintaining another libc strikes me as a poor idea (I want to get rid of
> > dietlibc :)  Ironically, both udevstart and udev are slightly smaller
> > when statically linked with glibc instead of klibc.
>
> huh?
> /sbin/udev.glibc.static 488096
> /sbin/udev.klibc.static  58056

Hrmm, I wonder what was up with my build last night.  Still doesn't seem
implausible to do glibc instead of klibc.
> plus
> /home/devel/harald/cvs/rpms/harald/udev/udev-029/udev-add.c:250: warning: Using
>   'getgrnam' in statically linked applications requires at runtime the shared li
> braries from the glibc version used for linking
> udev-add.o(.text+0x5ce):/home/devel/harald/cvs/rpms/harald/udev/udev-029/udev-a
> dd.c:236: warning: Using 'getpwnam' in statically linked applications requires
> at runtime the shared libraries from the glibc version used for linking
>
> ok, these could be patched out...

Yeah, no reason the static version really has to have these.  Or the
errors can be ignored (the shared libs are only needed for complex NSS
stuff)
> > Not really necessary, but some people might appreciate a "don't create
> >
> > device nodes" option and then just keep using their static /dev.
> > Obviously, this would imply UDEV_INITRD=no.  Also, if we're buying into
> > a dynamic, this isn't going to be the default.
> > The duplication between /etc/udev/udev.conf and /etc/sysconfig/udev
> >
> > strikes me as a potential source of confusion.  The config files are
> > roughly the same syntax, let's just use one of them (and then we can
> > have the other be a symlink if we really feel it's necessary, but I'd
> > lean against not).
>
> Thought about that, too. Sounds ok to me, as long as /etc/udev/udev.conf
> is sourceable by bash.

Looks like it is and that you already made this change.

Jeremy

[Harald Hoyer]

Jeremy Katz wrote:
> Right, but we run udevstart in the initrd, too.  So if the code to
> create them is all in udevstart (and we have rc.sysinit call udevstart
> instead of the start_udev wrapper), then everything should still get
> created at the same times and not have any newer problems.  Or if it
> can, I'm missing something entirely (not impossible)

The other possibility would be, not to --bind the ramfs /dev to the sysimage /.
Then our old /dev is there and start_udev can be run again after root is mounted rw.
We could strip down our dev.rpm and autoloading of modules would also work.
We only have to prevent udev from removing device nodes it has not created.
> > > The pam_console_setowner stuff really needs to just be a patch to
> > >
> > > pam_console_apply and then use that.  Otherwise, we have a second copy
> > > of that code to maintain and fix bugs in.  Nalin didn't seem against
> > > this when I mentioned it to him at dinner
> >
> > would be cool!
>
> Okay -- do you want to look at this or would you rather I do so?

I will tomorrow, if no one does it today...
> > > Any reason why udevstart can't be done after rhgb starts to avoid text
> > >
> > > seen before the graphical boot?
> >
> > You may see some udev messages, if root is mounted (ro) at the time modules are loaded,
> > which trigger hotplug events.
>
> Right, but for udev to be set as the hotplug handler, then it got set
> from the initrd and you're using a ramfs dev.  In which case /dev is not
> going to be read-only.  Do you have an example case?  And the downside
> here is that it makes the rhgb details pop open instead of remaining
> hidden?
>
> It just seems a shame to be adding more messages that are going to be
> potentially confusing before rhgb starts up.  It also makes it look like
> something is broken since you get the console font loading ([OK]), then
> welcome to fedora, then starting udev ([ok]).  The space between these
> just looks and feels awkward.

needs testing

[Harald Hoyer]

Harald Hoyer wrote:
> We only have to prevent udev from removing device nodes it has not created.

btw, I already have included a quickfix for this where udev does not remove
device nodes at all (only symlinks).

/etc/udev/udev.conf:
....
udev_remove_devicenodes="yes|no"
....

[Greg KH]

On Wed, Jul 14, 2004 at 05:00:45PM +0200, Harald Hoyer wrote:
> Harald Hoyer wrote:
> > We only have to prevent udev from removing device nodes it has not created.
>
> btw, I already have included a quickfix for this where udev does not remove
> device nodes at all (only symlinks).
>
> /etc/udev/udev.conf:
> ....
> udev_remove_devicenodes="yes|no"
> ....

Care to send that patch upstream?  :)

Oh, and udev-030 is out which fixes some bugs in udevstart, that non-x86
arches care about.

thanks,

greg k-h

[Harald Hoyer]

Your last mail has From: [e-mail] ??? :)

Greg KH wrote:
> On Wed, Jul 14, 2004 at 05:00:45PM +0200, Harald Hoyer wrote:
> > Harald Hoyer wrote:
> > > We only have to prevent udev from removing device nodes it has not created.
> >
> > btw, I already have included a quickfix for this where udev does not remove
> > device nodes at all (only symlinks).
> >
> > /etc/udev/udev.conf:
> > ....
> > udev_remove_devicenodes="yes|no"
> > ....
>
> Care to send that patch upstream?  :)
>
> Oh, and udev-030 is out which fixes some bugs in udevstart, that non-x86
> arches care about.
>
> thanks,
>
> greg k-h