Greetings,
One other call for modular binary support is end users. It's one thing to get them to use a provided tool to flash in one of several mix and match modules, it's quite a different matter to get them to actually compile something correctly and then flash it.
An idea I have for baremetal is to have it set up a callback table at the top of RAM for all of the useful (and possibly hardware dependant) functions. It's not too much of a leap to make a compile time decision to either:
1. End up by calling elfload and running baremetal which has it's own function library 2. link the baremetal setup in static and just call it.
With a bit of designing any payload should potentially be linkable againmst either LinuxBIOS to be called directly, or an ELF stub to be called externally.
The stub would likely have something like:
int printk(char *format, ...) { return call_table("printk", format ...); }
Otherwise, the payload will just link against LinuxBIOS.
The rest would be similar to the way mon can be standalone or linked in to init for beoboot.
I think some of the different opinions here really come not so much from philosophical differences as just different goals.
G'day, sjames
On Mon, 11 Aug 2003, ron minnich wrote:
On 10 Aug 2003, Eric W. Biederman wrote:
I haven't seen the numbers on the dreaded size overhead. So that argument does not yet convince me. If I can fit a whole IP/UDP stack a network driver, and printk in 16K I have trouble seeing the problem.
multiply that by, let's just say 4, for 4 elf payloads for 4 functions. At that point, I can no longer fit a kernel + linuxbios in 1 MB flash. At present I can barely fit one linuxbios + 1 stripped kernel.
I am right on the edge of being able to fit right now. Either I statically link in the VGABIOS code or I can't fit it. That's the issue for me.
Yes, I am well aware that we hope to have more compact ROMCC code, but that is not there right now.
Most of the things proposed so far are things I am primarily opposed to, at least except way out on the periphery. Callbacks are bad.
Callbacks are required if we hope to support VGA. There is no way around this.
Binary only code is bad.
Binary code support is required for future chipsets that, e.g., build wireless into the chipset. There will be many future software radios that are in chipsets, and you will not be able to get that in open source -- the FCC has a few things to say about that. Binary code support is inevitable. We won't be able to compile this code in, or build it as an ELF module. That's not going to be an option.
For linuxbios to succeed in future, we'll need support for these two things. I think this is a lamentable state of affairs. But that's how it is.
I think long-term the best way to fix it for all architectures is via emulation, but for the immediate-term we can make callback/binary support for the common(-est) case: the x86.
And the biggest reason I don't want to go there is because simple things tend to be reliable. And complex things tend to broken. And the extension extension looks to allow a lot of needless complexity into LinuxBIOS.
But the limits of poor PC design limit our ability to be simple. The original LinuxBIOS idea -- "Let Linux do it" -- was simple. We have found we need a bit more than that to be workable.
The single most common request I hear for LinuxBIOS is early VGA support -- early enough to see linuxbios messages. You have no idea how often this comes up -- or maybe you do :-)
I think we're going to need to do this in a reasonable way, or somebody will do it for us in an unreasonable way.
The biggest piece of code everyone has been arguing for including, the code to run a vgabios option rom, simply doesn't work in a lot of cases, and unless I have overlooked something the reason it doesn't work in a lot of cases is a design flaw, it doesn't aim for complete pcbios compliance.
That's a factor of time people have had to work on it. The code itself, I am told, has proven to be pretty solid for those operations it supports.
It's possible, the more I think of it, that what we really need is a payload for solid x86 emulation. That would buy us architecture-independence which we need. No callbacks either -- just emulate the trap and do the code for the callback. Much more reliable than callbacks. Very portable.
Still thinking .... more discussion welcome.
ron
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios