Date: Thu, 10 Jan 2002 20:17:10 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Mike Smith <msmith@hub.freebsd.org> Cc: current@freebsd.org Subject: Re: HEADS UP: module build process changed Message-ID: <3C3E6746.26986338@mindspring.com> References: <20020110173500.A10785@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C3E6746.26986338>