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 > >>------------------------------------- > >>1) mount /proc and /sys > >>2) mount /dev as ramfs > >>3) 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. > >>4) start udev, use udevsend as hotplug > >>5) load modules (eg. controller, filesystem) > >>6) umount /sys > >>7) 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. > >>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"] > > > > > > 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
