"Eric W. Biederman" wrote:
> Now that I have proven you can do a truly minimal stage1, we need to
> figure out what stage1 needs to do to properly support stage2. With
> the attitude of let's not code anything if we can possibly avoid it
> we will never figure out what we need to do in stage1. And
> hardwaremain.c will never stabalize.
[...]
> Definentily. The problem is that we currently don't have a standard
> stage2, besides the linux-kernel. So we can't do half the development
> in stage1 and half the development in stage2. And we need to build
> the simple powerful concepts that will effectively let stage1 give
> stage2 a blueprint of the motherboard. And that will make linuxBIOS
> an exercise in fill in the blanks for brining up a new motherboard.
>
> 3/4 of the code I'm proposing to write I fully intend to if not take
> out of linuxBIOS at least make it possible to compile out.
> hardwaremain.c has too many of these things presently hardcoded in it.
> It's nasty, and it seems to need some tweak for every other board.
> That is not a way to make maintainable software. And yes I'm talking
> about things that need to be done in stage1.
I think we agree quite a bit, so I snipped a lot.
I see stage1 and stage2 as being separate at a binary level, but not
necessarily beyond that, at this time. Just like the Linux kernel
includes bootstrapping code, such as the stub which decompresses the x86
kernel, I think linuxBIOS should include both stage1 and stage2 in CVS.
Start the separation now... but still exert complete control over the
codebase. That lets people replace stage2 if they would like, while
still providing the same end result for current linuxBIOS users. If
done right, the appearance of a small stage2 would be transparent to the
installer.
Thus, I think we -can- do half the devel in stage1, and half in stage2.
Long term (and perhaps even near term), stage2 for linux-kernel will
probably be necessary, IMHO...
--
Jeff Garzik | Disbelief, that's why you fail.
Building 1024 |
MandrakeSoft |
