Fwd: Next-generation thoughts

Hai Zaar haizaar at gmail.com
Mon Aug 15 16:55:03 PDT 2005


Here is additional input: Ruining
    while ! dmesg |grep -q 'NET: Registered protocol family 1$'; do
sleep 0.1; done
is not enough to prevent modprobe being called before its ready. The
problem is that from the moment initramfs becomes available, all other
running kernel subsystems can try using modprobe that is located
there. And only our /init is intelligent enough to wait :)

The solution is to install modprobe under different name during
initramfs creation - say /sbin/modprobe.bin. Then after
   while ! dmesg |grep -q 'NET: Registered protocol family 1$'; do
sleep 0.1; done
completes (i.e. we know that we are really ready to use modprobe), we just
    mv /sbin/modprobe.bin /sbin/modprobe
And now everyone can use it (including us)

P.S. I'm not on the list, so please CC me.

---------- Forwarded message ----------
From: Hai Zaar <haizaar at gmail.com>
Date: Aug 16, 2005 12:52 AM
Subject: Next-generation thoughts
To: livecd at linuxfromscratch.org


Hi, all!

I've just found the following thread
http://linuxfromscratch.org/pipermail/livecd/2005-February/000162.html
And would like to share some info.

Particularly considering the following:
(http://linuxfromscratch.org/pipermail/livecd/2005-February/000166.html)
Jeremy Huntwork wrote:

> Why does it need to be klibc-based? Wouldn't a glibc modprobe built
> statically suffice? Or is size the whole issue here?
>
> Yes, size is the only issue, since the stuff you put in initramfs stays
> there forever (it is never freed while the kernel is running, which
> means never).
Initramfs resides on tmpfs. So, the sure way to free its memory is
just to erase all of its contents. Gentoo does this, and from my
personal experience, it works well (based on statistics reported by
'free' command).

>
> For testing certainly a glibc-based modprobe would be fine, but for real
> usage it'd want to be smaller (uClibc, dietlibc, or klibc).
A.E. Petrakov is truly right on this topic:
http://linuxfromscratch.org/pipermail/livecd/2005-February/000189.html

Although, there is quite simple (yet still artificial) way to overcome
this. Something in the form (in the beginning of initramfs /init):
    while ! dmesg |grep -q 'NET: Registered protocol family 1$'; do
sleep 0.1; done
This hack spends only about 1sec or less of boot time (on P4 3.6Ghz)

Utilizing the above trick, one can easily construct initrams using
standard utilities - all that's left is to write /init script and
create cpio archive.

Contras:
1. The initramfs image is pretty large. For me it is 26M, of which 13M
are kernel modules, 7M are libraries and 5M are executables.

Pros:
1. Forget about klibc and/or busybox! In fact, mkinitramfs script just
do not need to compile anything! You may use standard tools, standard
bash language (I better like portable shell, then writing portable sh
scripts). Development is straight forward and easy to debug/update.
2. hotplug-ng is cool and cute, but it lacks pci.rc, which is probably
the one you generally want. Here you can just use hotplug scripts
directly to plug everything in. You can solve it using pcimodules (but
I'm not sure if it works with klibc) or port pci.rc manually, but IMHO
from here it starts being ugly.


After all, attaches is working /init I use to boot my LFS-6.1 based
system. Your comments are welcome.
My kernel does _not_ have any single fs/pci driver compiled in.
Everything is left in modules. The things that are inside are network
support and ramdisk support (without ramdisk, kernel fails to mount
_initramfs_ image. With fs drivers left in modules, one can not use
initrd anyway).

P.S. I'm not on the list, so please CC me.
--
Zaar




-- 
Zaar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: init
Type: application/octet-stream
Size: 7547 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/livecd/attachments/20050816/aa2ac55e/attachment.obj>


More information about the livecd mailing list