Re: Using SystemConfiguration API inside KEXT
Re: Using SystemConfiguration API inside KEXT
- Subject: Re: Using SystemConfiguration API inside KEXT
- From: Mo McRoberts <email@hidden>
- Date: Tue, 11 May 2010 22:04:25 +0100
On 11-May-2010, at 21:36, John B Brown wrote:
> Dear Kevin,
>
> Correct. No name calling. Technical questions.
>
> As you say, a decidedly non-portable framework
>
> (SystemConfiguration)
>
> even an Apple proprietary form, but the call as listed in the original note, <SystemConfiguration/SystemConfiguration.h>, looks like classic C language. Ie. look under the include tree.
>
> I suggested there was no way that call could produce the header because the file did not exist as the include call described.
>
> It got out of hand because the classic C language #include, according to my reading of the replies, apparently does not work in the Apple compile system. Or maybe it does. I looked at the referenced manual pages and still could not find anything to meet the original call.
#include works entirely as normal with respect to headers which ARE found in the include path, just as any other C compiler would.
however, GCC, when targeted at *-*-darwin* will ALSO search frameworks in the manner described by both the Apple and GCC project web/manual pages. The code for this is part of mainline GCC, but is only enabled on Darwin. It’s been around forever, though — thinking about it, there’s a good chance it pre-dates the existence of Linux.
You are assuming that because there is no /usr/include/SystemConfiguration/SystemConfiguration.h then #include does not work as normal, when in fact it does, if the requested header file exists in the include path. That is, #include <stdio.h> will look for (by default, and amongst other places) /usr/include/stdio.h. Mac OS X uses the GCC “-isysroot” compiler switch to target different SDKs for different operating system versions (this option is also a mainline part of GCC).
If you are compiling some software targeted at generic Unix systems and have the Developer Tools appropriately installed, then you need to concern yourself with anything Mac OS X-specific: it is a SuSv3-compliant operating system and behaves according to the specifications as any other certified Unix system does. Personally, I regularly build stuff on Mac OS X in tandem with both Linux and OpenSolaris with no modifications between platforms required at all (and only one of those is actually certified Unix right now…)
If, on the other hand, you are building software specific to Mac OS X, then the extensions come into play. When the include path has been exhausted, GCC and clang will search the framework path for matches for a given header in the form #include <FrameworkName/header.h>, exactly as described quite clearly in earlier messages in this thread. In searching the framework path, FrameworkName/header.h is expanded to /path/to/Framework.framework/Headers/header.h. So, SystemConfiguration/SystemConfiguration.h does not exist in any of the include paths, it must therefore be in one of the framework paths — in this case, it expands to /System/Library/Frameworks/SystemConfiguration.framework/Headers/SystemConfiguration.h, relative to the SDK root if one is specified… again, precisely as outlined earlier in this thread, and as described by the Apple documents. While it’s certainly a little different to what you might expect if you’re new at Mac OS X, it’s not especially complicated, is clearly explained in the docs, and isn’t a million miles away from GCC automatically prepending $exec_prefix/lib/gcc-lib/$target/$gcc_version/include to the include path. Or for GCC to have an __extension__() attribute. Or for GCC to have an #include_next preprocessor directive. Or other compilers to have #pragma. If you’re delving into platform-specific stuff, RTFMing helps enormously. In this case, the issue was the inclusion of a user-space framework header in a kernel extension… when you’re dealing with kernel extensions, it’s *going* to be platform-specific stuff.
What you think of as “classical C” doesn’t actually specify a whole lot in this regard. Sure, there are conventions, but vendors of both operating systems and compilers are free to adhere or not adhere to them, and in general almost always implemented some differences of a sort or other. I’m honestly not sure where you get the idea of Glibc being a prerequisite for any of this, but, y’know… to each their own.
(I’m just going to get this off my chest the once — feel free to disregard it if you wish: nothing in the above wasn’t pointed out to you from the outset — there are a lot of very experienced Mac developers on this list[0], including several who work for Apple; when several members of the list suggest that you’re incorrect, it’s probably best to stop and take stock rather than decrying everyone else as being wrong…)
M.
[0] I don’t count myself amongst them, incidentally. _______________________________________________
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