site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Is there any advantage to limiting the export symbol list for a kext? Ryan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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? I would assume it has the same positive/negative affects it does for userspace—limits namespace collision, reduces binary size, reduces time spent in runtime linker, etc. The speed impact may be less/more for kernel extensions because it's a totally different linker; I haven't done any testing to that affect. But for userspace applications it definitely helps. Beware though, I have a lot of problems stripping my IOKit kernel extensions. Things might be better on 10.5, but on 10.4 stripping our kernel extension would cause some pretty weird problems—from the small like kextd crashing randomly, to the very big, like the computer panicing early on in the boot cycle. I eventually got it working, but not 100% correct. Theoretically one should only have to leave in the C+ + vtable and class information for the IOKit classes, plus implementation of the classes themselves, but that turned out to be wrong. I had to leave in some random global variables (because ld complained about relocation entries, which I never fully understood) and some random C functions contained in a static library we link in (because the computer would just panic if I stripped them out, which has me totally baffled). I still recommend stripping, just be careful. This email sent to site_archiver@lists.apple.com