[PROPOSAL] enhanced table dumping

Eric W. Biederman ebiederman at lnxi.com
Thu Jan 20 09:03:01 CET 2005


Stefan Reinauer <stepan at openbios.org> writes:

> * Ronald G. Minnich <rminnich at lanl.gov> [050118 20:05]:
> > > I'd like to hear more about what Stefan had in mind for the 'small set of C
> > > functions'. Maybe the simplest way would be to pass the device tree itself
> to
> 
> > > the payload? I guess it wouldn't solve the binary/ascii problem, but it
> would
> 
> > > sure as hell make the code easy.
> > 
> > no, that will not work, due to the compiler portability issues. The Plan 9
> > C compiler won't work against GCC structs in any cases where
> > __attribute(xyz) has been used. We have to be careful here -- not all
> > payloads are compiled with gcc.
> > 
> > That's why I favor the s-expression approach. Binary trees are not going 
> > to work. 
> 
> What I meant is: There should be a library that people can use that
> parses s-expressions or whatever is used in the end and work on this
> information. So you can do foo=find-lbtable("memorymap");
> Any payload will want a set of functions like this that can just be
> compiled and linked. It is not about copying binary data from one edge
> to another, it is about not having every LinuxBIOS application developer
> looking for his favourite s-expression library and starting to look for
> tags and formats. Using a very simple parser s-expressions or xml is 
> perfectly fine for exchanging data. It won't have to do a lot of syntax
> or semantics checking either since we can probably rely on the fact that
> the table in memory was produced by another piece of code that has no
> form errors.

A reference implementation sounds sane.  We can't assume that everyone
will be using the same code or the latest code but having something
to compare with sounds good.  Except that a library has not been
factored out that is roughly what is in freebios/util/lb-dump directory
is.

Eric



More information about the coreboot mailing list