Mike Smith wrote:
> > In the book "Writing Linux DEvice Drivers", there is a neat bit
> > on how Linux does this. Effectively, they export all symbols
> > within the module load if there is no explicit symbol table
> > export call, and they export only the symbols that are requested,
> > if there is.
> I considered this approach, but couldn't work out a tidy way of making
> it work for the case where the module is statically compiled into the
You need to look at their "module.h" in the 2.1.x kernel.
They seem to use an alternate ELF section for most everything,
and then leave only the main symbols for the init/deinit,
which includes the symbol registration function, in the normal
ELF section where you'd expect it.
It's really tempting, since it avaids the problem with statically
linked modules with colliding symbol names.
> Effectively, you'd have to parse the linker set out of the .kld file,
> then feed it to objcopy to localise the symbols before linking.
I think this could be done, with a correctly arranged linker set,
but it'd be pretty annoying. 8-).
> There's no reason that, presuming a mechanism like this was devised,
> we couldn't dispense with the EXPORT_SYMS declaration and generate the
> list automatically, of course.
> I'd be happier with something like __attribute__((__export__)) on the
> declaration, of course. I'm also not fond of the "default to export
> all symbols" approach, but that's just a detail.
I think you could do this with a section other than "code" or
"data"; best to try to copy Linux, I think. 8-(.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message