In my ideal world here is how it works.
The firmware bootloader reads an ELF header from the first sector of
the disk. Looking at the ELF header it knows where everything else is
and loads the rest of the operating system and jumps to it.
There is a problem with that I cannot select among multiple images to
boot. So I install a different ELF image with the ELF header on the
first sector of my hard drive. This second image instead of being a
stripped down small and limited piece of code is a distribution of my OS
dedicated to the task of helping my decide which image to boot. Total
freedom.
And I have this working now without sweating the space in 64K of
firmware.
"H. Peter Anvin" <hpa@zytor.com> writes:
> Eric W. Biederman wrote:
>
> >
> > First it isn't an immediate problem because with an ELF image you
> > don't need a multistage bootloader. I can represent everything in one
> > file. Essentially a sparse coredump.
>
>
> For what definition of "everything"? I'm not being facetious, I think
> it's a fundamentally impossible statement to make, especially if the
> bootloader is interactive.
I know of no case for which a free-standing program or operating
system cannot be represented as an ELF image. Essentially the
non-interactive case.
For the interactive case you can I agree you can't please everyone.
But if it is trivial to write the interactive bootloader, with size
being the only problem with naive implementations I don't see a
problem. Though I suspect a bootloader running X will be overkill :)
> > If you are writing an intermediate loader it is a problem. An
> > intermediate loader needs OS services, and if you don't have those
> > services you are in trouble. For this purpose it is fair to call the
> > x86 BIOS, EFI, the SRM, and open firmware OS's.
> >
> > Personally when I want an OS I would like to use Linux. So I have
> > written a patch that allows me too load another OS from Linux, so in
> > those cases when I am writing an intermediate boot loader I can use
> > Linux. I admit I haven't gracefully solved all of the bootstrapping
> > cases but that is just a matter of time.
>
>
> Your intermediate Linux still needs to have all its devices.
Yep sure does.
> I was
> working for a while on a project to create an "intermediate Linux" which
> wouldn't claim to own the world but instead callback to the firmware; this
> would be a port of Linux to a sort of pseudo-architecture. I got a bit
> too busy, but I think it's a valid program.
I agree. But I also think it is valid to directly drive the devices
if you never plan on having the firmware driving the again. Or you at
least issue a firmware device reinitialization command before having
the firmware drive the device.
[snip PXE It doesn't matter if we agree]
> It's fundamentally about creating pervasive interfaces. My problem with
> several of your proposals is that they make well-established interfaces
> *less* pervasisve, which is a huge step in the wrong direction.
I agree. Except many of the pervasive interfaces today, do not
address my needs.
In particular an x86 BIOS is terrible for clusters. Where you have
hundreds of thousands of machines that you wish to manage remotely. I
have tried. I have worked with board vendors and BIOS manufacturers,
and at their best they can barely manage serial console support. And
they really don't help with anything beyond that. I have done a
better job with less code, in less time by rewriting the BIOS from
scratch.
So I am going to push for architecture neutral standards, that have
the potential to be even more pervasive than todays interfaces, because I
already need something different. And a core part of that for me is
the ELF file format. As I see it a bootloader saying everything is
ELF is as simplifying as the unix everything is a file concept.
Eric
-
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/
This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:00:11 EST