Stefan Reinauer <[EMAIL PROTECTED]> writes: > * Ronald G. Minnich <rminnich@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 _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios