[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: udev in initrd



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]