Re: Kernel Symbol Clarification
Re: Kernel Symbol Clarification
- Subject: Re: Kernel Symbol Clarification
- From: Terry Lambert <email@hidden>
- Date: Thu, 19 Jul 2007 00:08:56 -0700
Between objects in a KEXT, to prevent their visibility out5side to
another KEXT that links against it.
For example, say you have two KEXTs, and each, for whatever reason,
links against the object file "bob.o"., and you also want KEXT1 to
depend on KEXT2, so all the symbols in KEXT2 become visible to KEXT1.
so in bob.o, to prevent, for example, the function from colliding when
you tried to load KEXT1:
int foo(int arg);
you would:
__private_extern__ int foo(int arg);
both there and in the header. Then when the objects were relinked
into a single relocatable object, the symbols would be removed from
external visibility.
This is also generally useful when you have an internal function and
an external wrapper function, and you want to prevent people
accidently calling the internal varsion of the function. For example,
maybe the wrapper takes a mutex around the call, and internally, you
know you will hold the mutex already over the call, but you don't want
to make the mutex externally visible.
-- Terry
On Jul 18, 2007, at 11:55 PM, Duane Murphy wrote:
--- At Wed, 18 Jul 2007 22:59:55 -0700, Michael Smith wrote:
On Jul 18, 2007, at 12:03 PM, email@hidden
wrote:
Garth Cummings writes:
The kernel is one big monolithic namespace. All symbols in KEXTs
must
be unique across the system as they are linked into that one
namespace. If a KEXT defines a symbol that already exists, the KEXT
will not load.
Are you really sure about this? I thought the relocations were done
by kextload in userspace, and the only namespaces that are shared
are those of your kext and what it depends on.
Drew, you are correct for more recent MacOS systems.
Garth's description refers to a previous implementation.
An alternative for symbols that are exported between objects in a
kext, but which should not be visible outside it, is 'private
extern'.
Can you give an example of where private extern would help? I'm not
seeing why this matters? If as Drew says, all linking is done except
for
external dependencies before being put into the kernel.
I would expect that all symbols that could be located within the kext
would be satisfied first and then look for the rest of the symbols
outside the kext.
Am I not thinking about this correctly?
...Duane
_______________________________________________
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
_______________________________________________
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