Patches are on ftp.math.psu.edu/pub/viro, 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 devfs,
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: ipconfig.c.
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 replacement
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/