Supporting extension ROMs and beyond...

[steven james]

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 at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 

-- 
-------------------------steven james, director of research, linux labs
... ........ ..... ....                    230 peachtree st nw ste 2701
the original linux labs                             atlanta.ga.us 30303
      -since 1995                              http://www.linuxlabs.com
                                   office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------