On Fri, Nov 16, 2007 at 09:56:05AM -0500, James Carlson wrote: > Joerg Schilling writes: > > "Garrett D'Amore" <[EMAIL PROTECTED]> wrote: > > > > > I am thinking about using a mapfile to hide some symbols that would > > > otherwise be global in my kernel module. (This is because I want to use > > > more than a single .c file in my module, so I need some global symbols > > > at compile time, but I don't want to expose them outside of my module.) > > > > > > I notice that SPARC krtld does the same thing. But I see a note there > > > about a gotcha relating to ctfmerge. I'm hoping someone on this list > > > > Does this mean that on x86 or x64, there is no symbol hiding between kernel > > modules? > > Yes. We're all friends in the kernel. > > It's true on SPARC as well.
We're all friends, but we at least try to play nice: it is actually not the case that any kernel module can resolve undefined symbols from any other kernel module. The deal is that when you have an undefined symbol, that symbol can be resolved using one of these sources: - It can come from a "primary" module (unix, genunix, krtld) - It can come from a dependency (DT_NEEDED), e.g. ld -N misc/foo - It can come from a "modstub", which are basically symbols in the base kernel defined to load other modules As per the original question, it's a good idea when building a misc module to use a mapfile and symbol reduction to avoid unwanted dependencies. At some point a useful thing for us to do would be to extend this concept to the core kernel -- much pain over the years could have been saved if we scope-reduced the kernel down to a set of valid interfaces to call (e.g. DDI, VFS, and other semi-well-defined subsystems). But don't feel bad. Even with symbol scoping, we can still all bzero() each other ... :) -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
