At Thu, 20 Dec 2007 17:09:16 +1300, Eliot Blennerhassett wrote: > > Takashi Iwai wrote: > > At Wed, 19 Dec 2007 11:13:25 +1300, > > Eliot Blennerhassett wrote: > >> BTW is there any way to not export functions/variables that are used > >> only inside the kernel module? (but used between object files that make > >> up the module so cannot be made static) > > > > Remember that a driver can be built in a kernel, not as a module. > > > >> I.e. if the module was compiled as one huge sourcefile, almost > >> everything could be static. > > > > You can do it in that way, of course :) > > > Hmmm. Seems to be a general problem whether building a shared library, > or a kernel module. > > I.e. as soon as I have more than one source file in my lib or module, I > suddenly have to make some functions not static, and they become visible > globally. > > Is there no way to compile and link a.c and b.c so that only specific > entry points are visible before statically linking ab.o with the rest of > the kernel or making ab.o into a kernel module. The global symbols in modules aren't really exported to outside unless you set EXPORT_SYMBOL*(). The problem is rather a built-in driver. When you compile the driver in a kernel, it becomes all global to the kernel (not to modules) because it's a single object in the end. (For shared libraries, you can set Versions script to restrict the exported functions, BTW.) Anyway, a safer way is to use some unique prefix to each global function and variables. In the case of ALSA, usually we use snd_* for global objects. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel