udev in initrd

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