Re: loading a compressed ramdisk image
> > Your call. You can hardcode the command line and ramdisk path in the
> > loader as well. The loader needs to know where to find the ramdisk anyway,
> > right? (The kernel cannot load the ramdisk from some other storage BTW.)
> >
>
> Do you mean that the kernel and root image need to live on the same
> device? So if the kernel is on a floppy disk the root image can't be on
> the hard disk.
No, I didn't say that. The ramdisk has to be loaded to RAM prior to
passing control to the kernel, that's all. The bootloader takes care of
that.
> I'll definitely always use /dev/ram as the root device but I think I
> need to have the root image be configurable.
Even on x86 this is the bootloader's job. The Linux kernel cannot, prior
to mounting the root filesystem, access any filesystem to load the ramdisk
(your root filesystem) from. Catch-22, though you could conceivably hack
the kernel to mount some block device as root fs, read the ramdisk from
it, umount the root filesystem again and proceed as usual.
On PCs, you can have kernel and ramdisk on separate floppies, and either
bootstrap or kernel will prompt to insert the ramdisk floppy after the
kernel has loaded. I've not had to cope with that for a long time so I
can't remember if that was before starting the kernel or after. Look at
the ramdisk driver source to see if there's any hook to load from floppy.
This won't help your cause, though: all you can do is read the image from
a raw device, not a filesystem.
> I've only read the man pages for rdev and I'm still not clear on how it
> works. Does it mask a word in the kernel that has all of the
Read the source, then. Ethan explained it - rdev patches the bootloader
piggybacked on the compressed kernel image. I would assume this strategy
is way too primitive to do what you want (the existing piggybacks, not the
'patch the hell out of the bootloader').
Subscribe to linuxppc-dev to talk to more (and more experienced) kernel
hackers. This is getting a bit OT here.
Michael
Reply to: