[uClibc] static compiling
Rob Landley
rob at landley.net
Thu Feb 19 23:53:55 UTC 2004
On Wednesday 18 February 2004 10:29, Bennett Todd wrote:
> 2004-02-18T03:14:31 Rob Landley:
> > If you need a mini-system to bring up the real system, use an
> > initrd. (2.8 is going to strip the early setup stuff out of
> > the kernel and make an initramfs _mandatory_.
>
> Could you please be so kind as to expand on that bit? Is LILO,
> vmlinuz, and a root filesystem not going to suffice to boot 2.8?
> Will 2.8 no longer be able to work with root= and ro/rw boot
> parameters to directly boot onto a hard disk partition?
Part of the 2.6 build process already builds an initramfs, and the 2.6 boot
process extracts it and loads it into memory. It just doesn't run anything
out of it. (I've appended an old linux-kernel message from Al Viro about how
to test out initramfs in 2.6 if you want to play with it.)
The new initramfs will be linked into the vmlinuz image during the build,
rather than being a separate file. That's what's done now, anyway. Notice
that the 2.6 linux-kernel tarball has sprouted a "usr" directory, which
contains just skeleton code at the moment that generates and links in a more
or less empty initramfs file (which is a cpio style archive, which is
apparently less complicated than tarballs, search the archives for the
flamewar on that issue).
Right now, initramfs is just an optional replacement to initrd. /rootfs has
basically become a special ramfs which initramfs extracts stuff into. (note
this means you have to delete that stuff to free up the memory, before doing
your pivot_root to the real root and having your init script exec the real
init so it inherits PID 1. Whether or not you'll still have to do "echo
0x0100 > /proc/sys/kernel/real-root-dev" is an open question. I haven't
tried all this, by the way. Your mileage may vary. This is currently
"bleeding edge early adopters" stuff...)
In 2.7, they're going to take a lot of the nasty kernel code like automatic
NFS root partition mounting (and the corresponding dhcp code), and a lot of
the block device identification stuff (partition detection, etc) and move it
into the usr directory to make an initramfs do it as userspace processes.
(There's talk of having partitions eventually just be "device mapper" slices
of block devices, set up by udev. There was a recent linux-kernel flamewar
on the subject, a month or two back. It might help your google groups search
to know that Greg Kroah-Hartman was involved, I think. Basically, they're
going to have hotplug start up as soon as the initramfs is up, and _all_
device detection and configuration will be done by hotplug events, even
finding and mounting the root partition...)
Probably, at least a skeleton initramfs will always be generated by the linux
kernel build. Linus put his foot down a couple months ago saying that the
block device/partition detection code was never moving out of the linux
kernel source tarball, because without it the kernel was basically useless.
So what's likely is a couple of really thin userspace things (klibc and udev,
possibly) might move into the kernel tarball instead. (Or else your kernel
build will just assume they exist on your system...)
The details are still fuzzy, this is all 2.7 stuff. Those arguments haven't
happened yet. :)
Rob
-------------
Re: [PATCH] initrd with devfs enabled (Re: initrd and 2.6.0-test8)
Date: 2003-10-18 17:11
From: viro at parcelfarce.linux.theplanet.co.uk
To: Arkadiusz Miskiewicz <arekm at pld-linux.org>
CC: linux-kernel <linux-kernel at vger.kernel.org>
On Sat, Oct 18, 2003 at 11:56:04PM +0200, Arkadiusz Miskiewicz wrote:
> On Saturday 18 of October 2003 21:41, viro at parcelfarce.linux.theplanet.co.uk
> wrote:
> > OK, that should do it - the problems happened if you had devfs
> > enabled; in that case late-boot code does temporary mount of devfs over
> > rootfs /dev, which made /dev/initrd inaccessible. For setups without
> > devfs that didn't happen.
> >
> > Fix is trivial - put the file in question outside of /dev; IOW,
> > we simply replace "/dev/initrd" with "/initrd.image" in init/*. It works
> > here; please check if it fixes all initrd problems on your boxen.
> Works fine for me.
>
> btw. is it possible to do not use initrd with some fs and instead use
external
> initramfs image?
>
> I've tried to create initramfs image with unpacking initrd image, mounting
it
> over loop and creating cpio archive from that (find . | cpio -o -c >
> ../x.cpio), gzipping that cpio and placeing it instead of old initrd at
> /boot/initrd + lilo reload.
>
> It doesn't work that way unfortunately (test8 with your patch).
Yes and no - it *is* unpacked, but currently we have no code that would
try to run something from initramfs. If you want to play with that -
add something like run_init_process("/init"); right before the call of
prepare_namespace() in init/main.c (and be ready to have /init on
initramfs do the rest, obvoiusly).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
More information about the uClibc
mailing list