On Sun, 10 Mar 2002 00:00:18 +0100,
Francois Romieu <romieu@xxxxxxxxxx> wrote:
>Dominic Duval <dd@xxxxxxxx> :
>[...]
>> Sure, that would be the next logical steps. The current patch is more a
>> proof of concept than anything else. For example, something better could
>> be done with ipv6, in fact I'm not even sure how the ipv6 module (and
>> other sub-modules of ipv4) will react with all these modifications. I
>
>On a related note, could somebody elaborate on why the EXPORT_SYMBOL
>are done from net/netsyms.c ?
Historical reasons. The original method of exporting symbols required
header and trailer X macros and it was easier to have one file per
subsystem that did all the exports. With EXPORT_SYMBOL you can export
the symbols directly from the file that instantiates the symbol,
subject to these constraints :-
Files that use EXPORT_SYMBOL must be in the export-objs list in the
Makefile.
Files that use EXPORT_SYMBOL must have a globably unique name. You
cannot export from inode.c because there are multiple files called
inode.c.
There is a minor problem with the kernel build that recompiles all
files in the directory that export symbols if any file has changed.
|