Re: kext symbol exports?
Re: kext symbol exports?
- Subject: Re: kext symbol exports?
- From: Ryan McGann <email@hidden>
- Date: Sat, 11 Apr 2009 17:15:01 -0700
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?
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.
Ryan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden