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.
> 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. 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.
>>That's the thing with PXE and the BIOS too, for that matter: they might be specs
>>done by monkeys, but when it really counts, what you need is really there
>>(modulo bugs, but that applies to everything.)
>
> Except PXE isn't always there. In fact PXE is usually absent. If it
> was always there on x86 this would be a good argument. For those
> cases when I can't get firmware to do my network booting I put the
> Linux kernel on a floppy or a cd or whatever the firmware can boot off
> of and network boot with that.
PXE is there on the vast majority of all modern (1999 or later) network
cards. Those that aren't either have a socket or don't have any
provisions for network firmware whatsoever, as a rule.
> I do agree that having specs even when done by monkeys are good when
> they are widely implemented.
>
> But I see no reason why the open source community shouldn't drive the
> specs.
We could have, but we didn't. I DO NOT want to launch a competing spec.
> We have as much right as Intel or any other self appointed
> commitie. And open source is a great tool for providing defacto
> implementations.
Yes, but we're several years too late. PXE is the accepted spec, for as
much as it sucks (to its defense, the latest version of the PXE spec
actually does most of what you want it to be able to do, although few if
any commercial PXE specs implement these correctly to my experience.
I would *LOVE* to see a high-quality Open Source PXE implementation, for
several reasons:
a) To support older, socket-carrying network cards;
b) To put on a floppy or flash into your network ROM if your commercial
PXE firmware is too broken to live.
> And I have been doing this for over a year in production on thousands
> of machines so I do know that PXE is by no means necessary.
There are a lot of things that are "by no means necessary" if you look at
any one individual user.
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.
-hpa
-
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 Jan 31 2002 - 21:01:39 EST