Mike Smith wrote:
> In order to deal with this problem, I have changed the module build
> process so that symbols global to the module are converted to local
> symbols when the module is linked into the .kld/,ko file.  In order
> to allow modules that intentionally export symbols to continue to do
> so, a new module makefile variable 'EXPORT_SYMS' has been implemented.
> This variable may take three values; "YES" will revert to the
> traditional behaviour of exporting all globals.  It should typically
> only be used when converting a module from 4.x, or to quickly verify
> that a problem is due to a failure to export a symbol.  A list of
> symbol names may be given, and these symbols will be exported.  And
> thirdly, the name of a file may be given, and this file will be read
> for the list of symbols to export.

[ ... ]

> Questions and comments welcome.

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.

The way this works is that they substitute the symbol list at
the module load time, after the load, but before the relocation.

This is actually nicer, in that it leaves the symol list control
in the source file, rather than hiding it in the Makefile.

In addition, they have a moderately nify approach in that they
as a major/minor/minor version mask to each one, and then
exporte the version number (it seems they don't know how to
work linker sets and sections quite right yet, or they would not
need to be as careful to avoid multiple declaration of the
verstion value).

The version is the version of the module header files -- which
is basically the version that the module was compiled on -- and
you can mask them for interfaces that don't vary widely over
time (e.g. memcpy()), so that binary modules tend to work more
widely across Linux kernel versions.  There is an example in
the book of old (2.0.x) vs. new (2.1.x) modules, with how to
write one that's portable between both versions.

I rather like that all you have to do is use an EXPORT_SYM()
macro, and nothing has to be declared static...

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to