Supporting extension ROMs and beyond...

[SONE Takeshi]

On Fri, Aug 08, 2003 at 10:51:23AM -0600, Eric W. Biederman wrote:
> > Now if we want to have a way to choose seperate ELF payloads or direct 
> > linking them in at build time, that makes lots of sense to me. We can try 
> > to look at that. 
> 
> I am not certain about multiple payloads.  

I've seen there is no way to ensure images to not overwrite each
other.
When LinuxBIOS loads ELF image at the same location as itself,
it moves itself to top of memory (below 4GB).
Etherboot (>=5.1) relocates itself to the same top memory,
since it is usually safe place when loading kernel.
Other future bootloaders would do the same.

Probably this could be resolved by indicating LinuxBIOS's location
in the memory map of LinuxBIOS table?

> Taking boot loaders to the next step is a very interesting question.  For
> the normal case where traditional BIOS's work ADLO looks to be a very
> satisfying solution. 

If ADLO works at all.

> For things to think about.  The reason traditional BIOS's are 16bit
> real mode beasts is because Windows runs parts of them in vm86 mode.
> Which is why 32bit extensions are not common.

I've been thinking about the same thing.
I guess you refer to the DOS-based Windows (-95/98/Me).
Of couse the DOS applications like EMM386 and things like DPMI 
won't run with a BIOS which does it's job in 32-bit.
And nowadays nobody uses those application.

Open source applications I've seen so far (setup of Linux, GRUB, Etherboot,
LILO...) are calling BIOS from pure real mode, so they won't notice
if the BIOS services they are calling are in fact 32-bit code.
I'm not sure but I guess NT-based Windows and its bootloader are
like Linux and its bootloaders.

If we cut off some of lagacy applications, we can implement a
clean 32-bit minimum legacy layer.