On 8 Aug 2003, Eric W. Biederman wrote:
Several bugs fixes later and we have put the Bochs BIOS into LinuxBIOS. Which doesn't work on anything but x86....
I take your point, but is there any harm done if this is packaged as an extension, not a part of the core? I just can't see the harm in it. It lies somewhere between ELF modules and integration into the core.
I am concerned in large part with feature creep and future maintainability. I drew a line in the sand so we can see when we are going over it and are close to being in trouble.
No problem.
In the core we don't drive the hardware we initialize the hardware. We only drive the hardware that is needed to initialize other parts.
Yep, but that means we still actually do drive the hardware in some cases. We do that because Linux can't do it, or because we should do it in one place, not in every payload.
The problem is the complete lack of vga support is a common complaint I hear all the time. I'd like to resolve that complaint in a simple way. Bochs is neat, but not simple. Maybe, however, we can make it simpler. I really don't want to write x86 asm at this point, however. If I do this I want to do it by building on the VGA BIOS stuff I wrote for 1.0.
The VGA BIOS code in 1.0 has proven to be pretty easy to use for people, it's 32-bit code, and it's pretty easy to fix. Also, like the rest of LinuxBIOS, it has a very small assembly bit and the rest is C.
I think chain-loading ELF modules or calling multiple ELF modules is a harder, more complex, harder to build, and less efficient way to go.
And why can't you do this a kernel patch for your magic kernel bootloader?
yes, that's an interesting idea. I can do it for Linux. If we use Linux as the bootloader we're ok. But if people want 9load or plan 9 in there, then I have to do it over again for them. It's not just a linux world.
As it happens, I just found out that Plan 9 can boot Plan 9, so Plan 9 in the FLASH is not at all unrealistic. And I already have 9load in flash, and VGA support would be very nice.
ron