Re: [CFT] initramfs patch

From: Alon Ziv (
Date: Mon Jul 30 2001 - 11:25:27 EST

I wonder... May the initramfs be used also for loading modules ???
Hmm... it will require a pico-insmod that can run in the limited initramfs
environment, but I believe that's all !
Reminder-to-self: try this at home...
This may bring the long-awaited revolution in kernel building (everything
is a module!)


----- Original Message -----
From: "Alexander Viro" <>
To: <>
Cc: "Linus Torvalds" <>;
Sent: Monday, July 30, 2001 8:05
Subject: [CFT] initramfs patch

> Folks, IMO initramfs (aka. late boot in userland) is suitable
> for testing.
> Patches are on, namespaces-a-S8-pre2 and
> initramfs-a-S8-pre2 (the latter is against 2.4.8-pre2 + namespaces).
> It is supposed to be a drop-in replacement - any boot setup that works
> with vanilla 2.4 should work with it, initrd or not, with or without
> with loading from floppies, etc.
> In other words, if you boot normally with 2.4 and something breaks with
> initramfs - I want to know about that.
> Stuff that went in userland: choosing and mounting root, unpacking/loading
> initrd, running /linuxrc, handling nfsroot, finding and starting final
> init - basically, everything after do_basic_setup().
> The thing unpacks cpio archive (currently - linked into the kernel image)
> on root ramfs and execs /init. After that we are in userland code. Said
> code (source in init/init.c and init/nfsroot.c) emulates the vanilla
> 2.4 behaviour. You can replace it with your own - that's just the default
> that gives (OK, is supposed to give) a backwards-compatible behaviour.
> Thing that had not gone into the userland, but should be there:
> If somebody feels like writing a userland equivalent - I'd be very
> grateful to see it. Currently it's still in the kernel.
> Another thing that is definitely needed is less crude RPC (for nfsroot).
> Currently it's _very_ quick-and-dirty.
> At that stage I'm mostly interested in bug reports regarding the cases
> when behaviour differs from the vanilla tree. I _know_ that we need more
> elegant way to add initial archive to the kernel image. That's a
> separate issue and I'd rather deal with that once userland implementation
> of late-boot is decently debugged.
> Right now it's x86-only, but that's the matter of adding minimal
> of crt1.o for other platforms (i.e. code that picks argc, argv and envp
> and calls main() - 7 lines of assembler for x86 and probably about the
> same on other platforms). Equivalents of arch/i386/kernel/start.S (see
> the patch) are welcome.
> It should be pretty safe to debug, for a change - it either gets to
> starting /sbin/init (in which case we are done and safe) or it breaks
> before any local fs is mounted r/w.
> Linus, I'm not putting these patches in the posting - each of them is
> above 100Kb and that's way beyond any sane l-k limits. If you want
> to get them in email - tell and I'll send them. And yes, I'm going
> to split this stuff in small chunks when it will come to submitting
> it.
> Al
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to
> More majordomo info at
> Please read the FAQ at

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:44 EST