[LinuxBIOS] [v3][PATCH] stage0 and stage1 cleanup and improvements.

[Juergen Beisert]

On Friday 20 July 2007 00:02, Stefan Reinauer wrote:
> * Marc Jones <Marc.Jones at AMD.com> [070719 23:52]:
> > I only think that this is a problem with initram because it links to
> > stage0. Maybe we should reconsider that. Maybe it needs to stand alone.
> > Marc
>
> There are a few functions that we might want to share:
>
> - printk
> - the lar functions (?? not sure, maybe not even those.)
> - what else?
>
> One thing we had in v2 was 6 incarnations of print(k), each in 10
> incarnations, one for each log level. That made 60 functions just for
> pushing a few letters of _debug_ to the _developer_.
>
> Maybe we have to duplicate printk in the binary, but we should try to
> keep it one incarnation in the code.
>
> If it is only for printk, setting up a jump table is maybe not worth it.
>
> Though stage2 will have one, too.
>
> Modular design and it's advantages and disadvantages. I think we should
> try to go the "defined interface to stage0" way, as Juergen also
> suggested (I dont think this is a hack)

We could add a very thin translation layer between initram and stage0. This 
will not result into an API. Only the used functions get translated. We could 
use linker's  "--wrap" feature for all functions that tries to relative call 
functions in stage0. A script could extract all used stage0 symbols from 
initram.o, create on the fly the required translation code and link both into 
the final initram. If initram tries to call printf, it calls wrap_printf 
instead. And the generated wrap_printf functions calls stage0's printf, but 
calculates its correct entrypoint *at runtime*. This would enlarge initram by 
a few hundreds bytes, but would avoid to define an API (that grows and grows 
and will never be finished).

Juergen