Is there any advantage to limiting the export symbol list for a kext?
I worry that the kernel is a single namespace with a high potential for
symbol collision. Does using a symbol export list help to mitigate the
potential for symbol collision?
kexts are not the kernel.
Each extension, and the kernel, has a unique namespace. When a kext is linked into the running image, all of the namespaces for its dependencies are searched for the purpose of symbol resolution, but they remain unique namespaces.
When debugging, the debugger sees the union of all of these namespaces and acts as though it was a single space. It is for this reason that you should be careful with global symbols, as they may be masked by others of the same name and become invisible.
Apple encourages you to use the reverse DNS notation for naming your classes, and you should consider doing this for your local statics and globals if you are particularly concerned they will be masked at debug time as well.
You, like me, probably find this sort of thing immensely tedious to type, so I typically leverage the preprocessor:
<thing.h> #define DEVICE_CLASS com_widgetco_thing_driver #define COMMAND_CLASS com_widgetco_thing_command #define USERCLIENT_CLASS com_widgetco_thing_userclient
etc. This has the happy side-effect of making cut-and-paste code reuse easier too. 8)
= Mike
-- Excellence in any department can be attained only by the labor of a lifetime; it is not to be purchased at a lesser price - Samuel Johnson
|