On Friday 20 July 2007 00:02, Stefan Reinauer wrote: > * Marc Jones <[EMAIL PROTECTED]> [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 -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
