[EMAIL PROTECTED] writes:
> On 7 Feb, Ronald G Minnich wrote:
> > On 7 Feb 2001, Eric W. Biederman wrote:
> >
> >> Do we make linuxBIOS a subroutine library or do we make it a tightly
> >> focused first booter that can get you into a linux kernel in the rom
> >> that can do the hard work.
> >
> > well, you need a subroutine library to build the tightly focused first
> > booter.
> >
> > The way I've been trying to think of it is that we have a set of .c files,
> > some subset of which are compiled to build the first booter. The subset is
> > selected by the Config files.
> >
> > I'm not sure I know what the distinction you're getting to is.
>
> Put me on the list of people not sure what the distinction is. There
> are some things that need to be in the "bios" and somethings that don't
> need to be there. Those that don't need to be there should be done in
> the kernel. For those that do need to be in the bios we can do one of
> two things:
O.k. Our philosophies of where to put the code seem to be pretty much
in sync. We just have some questions as to how to do it. That helps.
We all seem to be in the camp of only put those things in the bios
that need to be there.
> 1 - Write an intel_main() and linuxbiosmain() that does everything and
> has enought #ifdef's in it to be able to configure it for anything.
>
> 2 - Have subroutines to make it easy to write a custom intel_main and
> linuxbiosmain().
3 - Have a main function that is not structured intel_main &
linuxbiosmain, but calls other functions.
Something like:
memory_init()
{
init_debug_print();
init_memory_controllers();
turn_on_the_memory();
main();
}
main()
{
init_debug_print();
init_chipset();
init_mainboard_tables();
boot_kernel();
}
And allow all/most of the directly called functions to be
overridden per chipset or possibly per mainboard. For people
demanding the ultimate in flexibilty the can skip calling that
main since it is trivial. But I don't think it should come to that.
If we can think through the problems in general we should get a fair
bit of design reuse out of it.
>
> Option one seems doomed to eventually fall apart and/or require a lot
> of people to hack the source code for where it doesn't meet their
> needs. Option two is inherently configurable to do pretty much
> anything.
Option one seems problematic the way we are going simply because it
was hacked together quickly.
Option two is also inherently confused, and is what I was referening
to as just a subroutine library. The problem there is you don't
have good focus. So it is hard to tell where to draw the line.
Option three I think has the best chance of the avoiding the
code dying in a sprawl. Because people can look and at main and
o.k. that is what linuxbios is doing how do I do that on my board.
> The current implementations of intel_main() and linuxbiosmain() are
> lacking for what I need to do. It happens that I can hi-jack
> intel_main() by having my mainboard_fixup() never return, but call
> linuxbiosmain() instead. However, this is ugly and sure to end up
> conflicting with someone's changes somewhere if it isn't the accepted
> practice.
Definentily not a good place to be. Before giving up on one
overriding main function we shoud look at redesigning what we
have so it handles what is there. There is a lot to be gained
by multiple boards doing things in the same way.
If not I'll settle for linuxBIOS not even trying to provide a main
function but just being a set of subroutines. But I really hope
we don't need to go there.
Eric
