May 2010 - Darwin-dev - lists.apple.com

Re: Using SystemConfiguration API inside KEXT
by Jamison Hope 11 May '10

11 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On May 11, 2010, at 4:36 PM, John B Brown wrote: As you say, a decidedly non-portable framework (SystemConfiguration) Well actually, according to the C language spec: -- Jamison Hope The PTR Group www.theptrgroup.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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. "A preprocessing directive of the form #include <h-char-sequence> new-line searches a sequence of implementation-deﬁned places for a header identiﬁed uniquely by the speciﬁed sequence between the<and>delimiters, and causes the replacement of that directive bythe entire contents of the header." -- http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf So, <SystemConfiguration/SystemConfiguration.h> just needs to uniquely identify a file. The spec doesn't say anything about slashes necessarily being interpreted as path directory delimiters. GCC (and Clang) on Mac OS X does treat it as a relative path, and will find <sys/cdefs.h> at /usr/include/sys/cdefs.h, but it also knows how to find headers inside of frameworks, in which case <Foo/Bar.h> translates to Foo.framework/Headers/Bar.h. I'm not sure which takes precedence (i.e. what if there's also a /usr/include/Foo/Bar.h). Anyway, the key phrase in the C specification is "implementation- defined". "#include <SystemConfiguration/SystemConfiguration.h>" *is* Standard C. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Using SystemConfiguration API inside KEXT
by Jens Alfke 11 May '10

11 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On May 11, 2010, at 1:36 PM, John B Brown wrote: —Jens _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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. The behavior of #include <...> is compiler- and OS-dependent. It just means the compiler should look at some unspecified set of system headers when resolving the filename. GCC has mechanisms for describing a set of system include directories to be searched. Mac OS X additionally enables a mainline GCC extension for 'frameworks', which are a handy way to package up headers with their libraries. These are specified using a different flag to GCC. There is nothing contrary to any standard going on here. Of course it's different from Linux. It's a different OS. Standards are written with the understanding that there are going to be multiple implementations that are different from each other. Deal with it. If you want behavior that's more like you're used to, consider writing your own GCC command lines and makefiles. Another peeve; the replies are missing the originals! In a technical discussion it's nice to know we are all discussing the same problem Please don't start a second religious war. There are several formats for replying to emails and everyone has their favorite. Flaming about them is incredibly tiresome and likely to get you moderated. If you want to know exactly what an email was in reply to, look at the threaded view in Thunderbird (which is what you seem to be using to read mail.) Or you can always refer to the In-Reply-To and References: message headers. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Using SystemConfiguration API inside KEXT
by Amanda Walker 11 May '10

11 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On May 11, 2010, at 4:36 PM, John B Brown wrote: > 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 exactly as it does on any other C language platform. Apple's build environment overrides the include path to include more than /usr/include before invoking the compiler, much as 'make' and other build environments often do. That said, assuming that everything will work the way it works in Linux is going to lead to frustration. A Darwin or Mac OS X machine is not a Linux box. --Amanda _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Using SystemConfiguration API inside KEXT
by Mo McRoberts 11 May '10

11 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com 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 (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Using SystemConfiguration API inside KEXT
by John B Brown 11 May '10

11 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 Dear Kevin, Correct. No name calling. Technical questions. As you say, a decidedly non-portable framework (SystemConfiguration) I apologize; I got carried away in the moment. It will not happen again. Shalom, John B. Brown. [jbb(a)vcn.com] 358 High Street, Buffalo, Wyoming 82834 "Freedom is not worth having if it does not include the freedom to make mistakes" Mahatma Gandhi "If any question why we died, tell them, because our fathers lied." Rudyard Kipling "A man who does not know the truth is just an idiot but a man who knows the truth and calls it a lie is a crook." Bertolt Brecht "I wonder whether the world is being run by smart people who are putting us on or by imbeciles who really mean it." Mark Twain _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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. Another peeve; the replies are missing the originals! In a technical discussion it's nice to know we are all discussing the same problem, not some attitude prompted by zeal. When the originals are omitted, what is there to discuss? I guess I got really pissed because all the replies were incomplete. And then there were the random insults to boot. On 5/11/10 2:17 PM, Kevin Van Vechten wrote: (SystemConfiguration framework) This email sent to site_archiver(a)lists.apple.com

1 0

Re: Using SystemConfiguration API inside KEXT
by Kevin Van Vechten 11 May '10

11 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com As list moderator I'm going to ask only once that the name calling cease from all parties. This list is for technical discussion. John, Since I'm feeling charitable, I'll respond to your question. Virtually all systems provide extensions in some form, and Mac OS X is no different. Your question involves a decidedly non-portable aspect of Mac OS X (SystemConfiguration framework) so portability of the tool chain should not be a concern when the API itself is not portable. The definition of open source per <http://opensource.org/docs/osd> doesn't include any references to portability. And finally, on the topic of portability, Mac OS X conforms to the Single Unix Specification version 3. Kevin On May 11, 2010, at 4:01 PM, John B Brown wrote: > Dear Jean-Daniel, > > Right! An Apple hater. > > As I said before, stop wasting bandwidth. Open source means open portability. How does adopting a "very special version" of gcc or anything else met those specs? > > GET A LIFE! > > Shalom, > > John B. Brown. > [jbb(a)vcn.com] > 358 High Street, > Buffalo, Wyoming > 82834 _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Using SystemConfiguration API inside KEXT
by John B Brown 11 May '10

11 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 Dear Jean-Daniel, Right! An Apple hater. GET A LIFE! Shalom, John B. Brown. [jbb(a)vcn.com] 358 High Street, Buffalo, Wyoming 82834 "Freedom is not worth having if it does not include the freedom to make mistakes" Mahatma Gandhi "If any question why we died, tell them, because our fathers lied." Rudyard Kipling "A man who does not know the truth is just an idiot but a man who knows the truth and calls it a lie is a crook." Bertolt Brecht "I wonder whether the world is being run by smart people who are putting us on or by imbeciles who really mean it." Mark Twain And so what ? Anyway Apple is moving away gcc by developing a closed proprietary compiler call clang. Hum wait, my bad, clang is OpenSource and released under the BSD license. Just out of curiosity, can you tell me how an apple hater end on an Apple developer mailing list ? Le 11 mai 2010 à 21:12, John B Brown a écrit : Dear Folk, I do believe the first clue to the general lie that Apple supports a legitimate port of the GNU compiler system is the fact that Apple has not ported Glibc to the Mac OS. DUH! On 5/11/10 12:15 PM, David Leimbach wrote: Reading documentation is bullshit too! On Tue, May 11, 2010 at 11:08 AM, Mo McRoberts<mo(a)nevali.net> wrote: On 11-May-2010, at 19:00, John B Brown wrote: Dear Folk, has screwed up the C and GNU compiler system. This is NOT porting, it is pulling a SUN; call it standard but make it proprietary. The framework-supporting extensions have been part of GCC for, literally, years. I might be wrong, but I’m pretty sure they were part of the enhancements which NeXT contributed back to the GCC project as part of support for Objective-C. It just happens that GCC only enables this functionality when built for Darwin, but it’s part of the mainline source (indeed, there have been plenty of people over the years asking if it can be enabled on other platforms, too). In this case, looking in framework paths for headers is a pretty straightforward backwards-compatible enhancement. Not exactly “pure BULLSHIT”, whichever way you look at it. You don’t ignore the workings of the C and GNU compilers (which in many cases are one and the same — clang behaves the same way, though, for obvious reasons); you just RTFM when developing on the platform and be aware that the compilers do more on Darwin than they do on other systems. There are *dozens* of platform-specific aspects to the GNU Compiler System and Binutils. Are they all bullshit, too? M. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/leimy2k%40gmail.com This email sent to leimy2k(a)gmail.com Shalom, John B. Brown. [jbb(a)vcn.com] 358 High Street, Buffalo, Wyoming 82834 "Freedom is not worth having if it does not include the freedom to make mistakes" Mahatma Gandhi "If any question why we died, tell them, because our fathers lied." Rudyard Kipling "A man who does not know the truth is just an idiot but a man who knows the truth and calls it a lie is a crook." Bertolt Brecht "I wonder whether the world is being run by smart people who are putting us on or by imbeciles who really mean it." Mark Twain _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/devlists%40shadowlab.org -- Jean-Daniel _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… As I said before, stop wasting bandwidth. Open source means open portability. How does adopting a "very special version" of gcc or anything else met those specs? On 5/11/10 1:18 PM, Jean-Daniel Dupas wrote: I see that, in addition to screwing up other GNU utilities, Apple In order to write and compile C code on an Apple you must ignore the workings of the C and GNU compilers and use a proprietary Apple system. That is pure BULLSHIT! This email sent to devlists(a)shadowlab.org This email sent to site_archiver(a)lists.apple.com

1 0

Re: Using SystemConfiguration API inside KEXT
by David Leimbach 11 May '10

11 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ankNRGnBpagA6N/8hBMs4kQKhpqt6FMCsWKFQ+1UtsE=; b=dZvAVV5KgfgXWqMrWul+NpaYB04IT19SIS5cgnYnz9RzQXHqoV05F8pTmqfXJeeLj8 d+0hWA2oEicFJkEcU/2+9i3VOKJ3oRpcb+XWSpJcUoQ7NOHrfy2tRqQ2f1a8eCZzXI0k R6w8VDCC/smqjhRi2oV0qsk/Y1scaTAKeUGF8= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=V5K/BeBC253lVK4n/Ru3SVlH5BD0nGh+wH4IC+u3UzKK5U+7sCsW4duH0i7Ce5v21i uBfy5DWu9FfJY8LbR0T1ie3rLY/tMDdEpRfg7JQSd+dmFlx3LmwyN5VlSpVRH2jUKoVe zdOC0FY94gfBE/p13LuEhG/0zm9IkekAx+YSQ= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Using SystemConfiguration API inside KEXT
by Jens Alfke 11 May '10

11 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On May 11, 2010, at 12:12 PM, John B Brown wrote: Otherwise: I suggest the rest of us stop feeding the troll. —Jens _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I do believe the first clue to the general lie that Apple supports a legitimate port of the GNU compiler system is the fact that Apple has not ported Glibc to the Mac OS. DUH! On the slim chance that John is sincere: You're in a pretty deep hole. If you want to be taken seriously by anyone on this list, I advise you to stop digging. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Using SystemConfiguration API inside KEXT
by Mo McRoberts 11 May '10

11 May '10

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 11-May-2010, at 20:12, John B Brown wrote: > Dear Folk, > > I do believe the first clue to the general lie that Apple supports a legitimate port of the GNU compiler system is the fact that Apple has not ported Glibc to the Mac OS. > DUH! Just… wow. Why on earth would they do that? libSystem predates glibc by (off the top of my head) a decade or so? And, of course, does things which glibc doesn’t. And, in 10.5, is certified SuSv3-compliant. And, er, glibc isn’t part of the GNU Compiler System. Neither is binutils, for what it’s worth. GCC targets loads of platforms on which glibc doesn’t run. In fact, the _majority_ of platforms targeted by GCC aren’t supported by glibc. If the Glibc team wants to port to Darwin, they can — there’s nothing secret in the user-kernel interface (though it can change when a new release arrives, of course). So. In other words. What the hell are you babbling on about? M. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0