Which "normal" functions do you mean? Here's a short summary of my
understanding of symbols in the kernel...
Any source file can refer to symbols defined in the same source file
(that's how e.g., hm2_register in hostmot2.c can refer to
hm2_print_modules in the same file).
A kernel module can refer to non-static symbols defined in a different
source file within the same kernel module (that's how e.g., raw.c can
refer to hm2_print_modules which is defined in hostmot2.c -- both are
linked into the same kernel module, hostmot2.ko).
A kernel module can refer to symbols defined in a previously-loaded
module or in the built-in parts of the kernel when it is exported with
EXPORT_SYMBOL (that's how e.g., hm2_pci.c can refer to hal_init which
is in hal.ko and exported with EXPORT_SYMBOL)
A kernel module which is declared to have the GPL license can
additionally refer to symbols exported with EXPORT_SYMBOL_GPL.
In all these cases, it's also necessary to have the declaration of the
function earlier in the source than the use of the function.
There are some other possibilities as well. For instance,
hm2_encoder_get_reg_count is called in a way that looks like a function,
but is a macro that is is expanded into the respective code every time
the macro is used. And rtapi_mutex_give is a function delcared in a
header as __inline__, so its definition is likewise included
automatically by the compiler anywhere it is used.
Macros and inlines are generally used where the "guts" of the macro or
function will be so extremely trivial that the overhead of calling them
outweighs the function itself--for instance, a favorite example of mine
is that given
struct S { double x, y; };
void initialize_S(struct S *s, double x, double y)
{ s->x=x; s->y=y; }
the x86 code to *call* initialize_S is bigger than the code of
initialize_S itself.
(In a few cases there is rather nontrival code in .h files. The one I
know of is my fault, and emc2 would be improved by moving them to .c
files--The parport-related functions in hal_parport.h are the main
example of this)
If you really probe the boundaries of these rules, you'll probably break
builds with "--enable-simulator", because it is a userspace imitation
of the kernel linker using dlopen/dlsym--just enough of an imitation to
make the currently existing non-driver realtime components work. As
your current work is in hostmot2 you don't have to worry about this
because hostmot2, like other hardware drivers, isn't built at all when
--enable-simulator is specified.
Jeff
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
