site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com int foo(int arg); you would: __private_extern__ int foo(int arg); -- Terry --- At Wed, 18 Jul 2007 22:59:55 -0700, Michael Smith wrote: 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. 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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/tlambert%40apple.com _______________________________________________ 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... 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: 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. On Jul 18, 2007, at 11:55 PM, Duane Murphy wrote: On Jul 18, 2007, at 12:03 PM, darwin-dev-request@lists.apple.com 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. 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. This email sent to tlambert@apple.com This email sent to site_archiver@lists.apple.com