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
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
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
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
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
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
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
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
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.
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
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.
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
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
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
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
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
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
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
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
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
Owen Taylor (otaylor@redhat.com) 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
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
Florian La Roche (laroche@redhat.com) 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
On Tue, Jul 06, 2004 at 06:50:36PM -0400, Bill Nottingham wrote:
Owen Taylor (otaylor@redhat.com) 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
Greg KH (greg@kroah.com) 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
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
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.
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
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
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
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 :-)
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 alexl@redhat.com alla@lysator.liu.se 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!
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
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
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! :)
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
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
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
Your last mail has From: greg@redhat.com ??? :)
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
devel@lists.stg.fedoraproject.org
-
Alan Cox -
Alexander Larsson -
Bill Nottingham -
David Zeuthen -
Florian La Roche -
Greg KH -
Harald Hoyer -
Jeremy Katz -
Nicolas Mailhot -
Owen Taylor -
Thomas Woerner