[EMAIL PROTECTED] writes:
> On 7 Feb, Ronald G Minnich wrote:
> > On 7 Feb 2001, Eric W. Biederman wrote:
> >
> >> To actually have integration it looks like we are going to have
> >> to introduce some kind of arch directory. There are just
> >> so many header files that change when you switch to a 64 bit
> >> architecture.
> >
> > not a problem.
> >
> >
> >> Then all linuxBIOS
> >> becomes is linuxbiosmain.c and it's supporting functions.
> >
> > sounds good.
> >
> >> A second point. Currently we hardcode the location of the kernel
> >> image and where it should be uncompressed in memory into linuxbios.
> >> What I would like to do unless someone has an objection is:
> >> (a) Implement my kexec interface for starting a kernel from linuxBIOS.
> > ok
>
> Could you give a very brief description of the kexec "api"? I'm
> currious about how it is different and/or better than the current
> system.
It's intial target is booting kernels over the network, without having
to change processor modes. It should not be operating system dependant.
The image format is an elf executable. ELF is very suitable for
this because the executable format after the elf header (which lists
the entry point) is the program header. Which just where chunks of the
file go into memory. Usually the ramdisk is one segment of the file,
and the kernel is another.
With a small wrapper program it is easy to encode command lines,
ramdisk parameters, or anything else into the ELF image.
There is also a slot for passing a command line, and some unprobeable
hardware parameters.
There are no callbacks.
The advantage over what we currently do are:
a) No weird changes from kernel to kernel
b) You can have different kernel start addresses and load kernels into
different places in memory.
c) requires less code than what we currently do.
d) You can test the kernel before flashing it into ram.
And with a little care we can set the kernel and linuxBIOS as independantly
flashable.
This is what I have done with ron's lobos. Idea.
> >> (b) move the responsibility of decompression into the kernel image
> >> itself. This can still be used by the BSD's if they choose to.
> >
> > if you think that's the best thing to do.
>
> On 7 Feb, Eric W. Biederman wrote:
> > I think so. The lazy reason is that it is a pain to extra an ELF
> > header from a gzipped image.
> >
> > The reason inspired by lazyness are
> > (a) We need something like this for transfering these kernels over the
> > network anyway. At least I need to and I'm aiming having one
> > set of tools to do the work.
> > (b) This should keep the linuxBIOS code simple while allowing us
> > to change to a different compression algorithm if we feel like it.
>
> I take it that you are wanting to use and ELF image and our current
> system doesn't? What is the advantage of an ELF image? Is it more
> porable or something like that?
see kexec api.
>
> >> (c) Implement a search algorithm in the rom where we look for a
> >> ELF header to find the kernel. Instead of hardcoding its
> >> location into ROM.
>
> I need to be able to boot either of at least 2 images from a paged
> flash chip. Wouldn't a search algorithm work against me?
Possibly. Maybe not. My thought was simply have something walk through
rom, and for each image it found increment a counter. So you could
boot kernel 1 or kernel 2 or kernel 3. You just set something in
the CMOS or the flash saying what to boot. A pointer might be just
as good. Figuring out what we need to boot multiple kernels from
the flash and how to fallback and revert if a new one fails is my
challenge. The trick is so you can make the kernels indepedently
erasable without killing each other.
Eric
