Ronald G Minnich wrote:
> On Mon, 26 Feb 2001 [EMAIL PROTECTED] wrote:
>
> > So the question becomes: How strongly do we believe that "if the
> > kernel can the kernel must"? How much of hardwaremain.c should be
> > moved into the kernel?
>
> that's a question for the list. I would like to hear some other comments.
Unless there are any problems with getting code into a mainstream kernel,
I think the division should be:
LinuxBIOS:
minimal
protected mode (x86), L1/L2 cache, ram init,
debug serial port (via superio), port 80 hardware (or alternates)
unzip kernel to ram
Kernel
anything needed for accessing boot device (root fs). pci setup, irq setup,
etc
of course anything that's a module could be compiled in so each application
can choose.
Modules/userlevel code (init)
anything else - anything that is flaky and makes debugging harder.
it shouldn't take any more space no matter where you do something
if you're careful. and usually userspace / filesystem space is
easier to code compared to assembly/flash.
a few cases... modular unix domain sockets and other modules
that can't be used for booting could make flash requirement
smaller, for people with harddisks that just want faster booting
or whatever and don't need flash root fs. but you still have
*choice*
>
>
> I am on travel this week so will not be writing much, but I think we're
> all interested in some ideas.
>
> > At this point I'm looking for inspiration on this as I don't feel that
> > I know the right answer.
>
> if moving this stuff to the kernel makes life too hard, then we need to
> find a way to do it in linuxbios without making the simple cases hard
> (i.e. most mainboards) but still make the harder cases doable (i.e.
> multiple northbridge, peer busses, multiple superios, etc. )
>
> ron
