"Jan Kok" <[EMAIL PROTECTED]> writes:
> Can Eric or someone explain what the 'driver' command to NLBConfig.py is all
> about? I understand that it forces the
>
> given .o file to be linked in, regardless of whether there are any references
> from outside to symbols in the .o file. But if there are no such references,
> how can code in the .o file be accessed? What is the mechanism by which such
> driver code is accessed? Is there a document somewhere that talks about this?
Sorry. No document yet. The method I use is I place a structure in a special
section of the ELF image, and then I can find that structure. The driver stuff
becomes especially important as we start building bootloaders that
share source with the main linuxBIOS tree.
> Also, I'm puzzled and curious about the syntax of the code fragment below, found
> in src/rom/rom_fill_inbuf.c . It sort of looks like rom_stream is being defined
> as an instance of a struct, and the members are being initialized, but
>
> a) who says member names can begin with "."? I don't see it in The C
> Programming Language, 2nd Ed. by K&R, and I don't see it in the extensions
> listed in the gcc documentation (although it mentions that "$" is allowed as an
> extension).
> b) I also don't see where <member>=<value> is allowed for initialization. The
> standard way is { <value>, <value>...}
a & b actually come from the second ISO C standard C90 I believe. The format
.<name> = <value>, as an alternative to <value, <value>.
named structure initializers are much more maintainable when strucutre
elements change.
> static struct stream rom_stream __stream = {
> .init = init_bytes,
> .read = read_bytes,
The __stream is actually a define that forces the structure into the appropriate
ELF section. And then we just read through that ELF section to find the appopriate
objects.
Eric
