Ronald G Minnich <[EMAIL PROTECTED]> writes:
> On 19 Jun 2001, Eric W. Biederman wrote:
>
> > Ron my 2.4.2 kexec stuff works well. I'm very dubious about a bootloader
> > in the kernel though. I can squeeze a network bootloader into 8KB of
> > user space so space is not super precious. I suspect anything in the
> > kernel will be a maintenance nightmare.
>
> It bugs me too but consider this: I have a redhat CD. I need to mount that
> thing and boot the kernel on it. The redhat CD is NOT going to have your
> user-mode kexec stuff on it. Users really want to say stuff like
> root=/dev/hdc kernel=/boot/generic.gz
> to some kind of boot loader.
>
> Basically the problem is this: how do we give people the capability they
> have right now with "normal" bioses, which allow them to boot an arbitrary
> kernel from CD/floppy/hdax/whatever with just about any Linux file system.
> This question first came up with some folks who had a linuxbios machine, a
> redhat CD, and a totally blank hda. There was NOTHING I could do to help
> them, save tell them "put in old BIOS chip". That's not a great answer.
Agreed.
> To support these normal uses, we are going to need to be able to mount
> arbitrary media and boot kernels on that media. We can't assume the
> presence of Kexec/Monte/LOBOS/bootimg programs on the media -- we didn't
> create it. All we've got is what is in flash.
Agreed. For this we need a default interface to linuxBIOS that does
a good job with this stuff.
> So what to do? I can't come up with any good way save doing it in-kernel
> -- except maybe doing some sort of exec but supplying the image for the
> exec from compressed in-kernel code. That seems much harder than just
> doing it in-kernel.
>
>
> one other possibility is to have an rdimage in the kernel, which you put
> in ramdisk, mount as root, and run. But that sure seems complicated to me.
To a certain extent that is what I have been doing with my ELF images.
mkelfImage puts everything together all nice and neat. There are
several ways to get a minimal userspace small enough to fit
in ROM. Basically they boil down to either a ramdisk, or something
like cramfs on a mtd partition.
> So what can we do? I'm not sure.
Ron we can worry about the method that we delivery the user space a
little later. Right now we need to build a user space bootloader that
is capable of doing what you need. For x86 all of the knowhow
everything is there. All it takes is bundling it in a small enough
package to fit in the rom.
My mkelfImage stuff allows me to boot arbitrary kernels.
My kexec stuff allows booting those arbitrary kernels from linux.
This code has been in production use for months on x86 so all of the
basic kinks have been worked out.
For the situtation you describe I agree saying prep the image
and boot over the network is also not a desirable solution. So
my network bootloader is not sufficient. However it is a good proof
of concept.
Ron what I would do is start with my network boot client, as a
starting point for small code. I can use my own extremly minimal
libc or uclibc. Using uclibc is where I want to go long term.
Build a booloader that has the requested features. And if we can get
it down small enough you are in.
Otherwise we need a variation that will attempt to an ELF image off of
the first couple sectors of disk, and doesn't do the conversion, and
doesn't need filesystem support from the kernel. Needing a new
bootfloppy/media for a strange machine setup assuming nothing else
needs to be changed is reasonable.
Ron please let's prototype this with an implementation that can be fit
on a boot floppy like my current nbc code is. That isn't perfect but
it will let everyone compare notes using a machine that has a legacy
BIOS on it.
Eric
