Re: some tiny and dumb questions

Albert D. Cahalan (acahalan@cs.uml.edu)
Mon, 18 May 1998 09:54:48 -0400 (EDT)


>>> firmware should be linked directly into the module.
>>> It's fairly simple to write a tool that translates an
>>> arbitrary binary file into an equivalent C array declaration...
>>
>> I've always wondered why we need to do that. Couldn't we just
>> create a .o file directly? The base name of the input file would
>> be a good choice for the symbol name.
>
> See hex2hex and bin2hex in drivers/sound.

No, those still require the compiler. Why not have a tool that reads
in the raw data and produces an ELF object file all by itself?
That would get rid of the extra step with the compiler.

>> the kernel and make that data itself available? When I get some time,
>> I'd like to put full symbol information in the kernel like most
>> other modern unix systems do.
>
> You mean pack System.map on the end of the zImage perhaps as a
> second gzip file ?

That would be fine, as long as it can show up as /proc/System.map.gz
or become part of /proc/ksyms. It would be best to have separate
binary index and data files. I don't really care how it is done, as
long as the data is part of the *zImage and is available in /proc.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu