site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On 22 Nov 2008, at 19:48, Terry Lambert wrote: /* * @OSF_COPYRIGHT@ */ Thanks, Jonas _______________________________________________ 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... On Nov 22, 2008, at 2:38 AM, Jonas Maebe <jonas.maebe@elis.ugent.be> wrote: I cannot find any document anywhere explaining what this marker means. If it does mean that it is licensed like the Mach kernel sources on Sourceforge, then there is no problem for me to distribute the file (the license forbids taking away that permission, and the iPhone SDK license agreement also explicitly mentions that in those cases the NDA/no distribution/no derivative works/... requirements do not apply). There is no way you will get an official anser to a question like this on a mailing list. This is not an official support channel, even if people who happen to work at Apple sometimes hang out here and post personal opinions. For an official answer, you should contact DTS and ask. I did contact DTS with a licensing question several years ago (about permission to distribute translations of the Apple Universal Interfaces), and they redirected me to sw.license@apple.com. I sent an email there, and never even got an acknowledgement of my request. About a month ago, I again sent them an email asking whether or not APSL-licensed files in the iPhone SDK can be modified and redistributed under the APSL terms now that the NDA is lifted. Again, I have not heard anything back. So as far as I can tell, sw.license@apple.com is a black hole (except maybe if you represent a million dollar customer of Apple or so). I still have some hopes regarding my second mail because someone at Apple was going to poke them about it. Still, they obviously have other things to do than answering requests from an individual open source developer (regardless of how many commercial companies use our product). Furthermore, the @OSF_COPYRIGHT@ tag also appears in many regular Darwin files (e.g., in 517 of the xnu-1228.7.58 files). Since several people responsible for the packaging and releasing of Darwin sources are here, I hoped that they could give an indication of what it means (maybe just a reference to some licensing document somewhere on the Darwin site that Google doesn't index). In these xnu files, @OSF_COPYRIGHT@ does in fact appear to be always followed by the full OSF license in linked to in my original mail. Maybe some sort of license stripping was done for the iPhone SDK to avoid marking certain iPhone-specific files as APSL. Or conversely, maybe only the tags are present in Apple's internal sources and simply no license /insertion/ was performed based on these tags -- one more reason why I think the Darwin packagers may be able to answer my question, even if only in the sense that "based on this tag we insert this text into the sources when preparing them for distribution. The OSF license would however remain applicable in such situations (since that one is not Apple's call to remove). All that said, were I in your position, I would side-step the issue entirely by doing a machine translation at install time, which is the time-honored approach to dealing with license issues by not dealing with them. Perl, Ruby, Python, etc., all take this approach. For this particular header file (which is fortunately the only one which I need from the iPhone SDK for our base run time library), that would indeed be an option since it is so simple. General machine translation of C headers usually breaks down horribly in my experience though. But maybe gen_bridge_metadata(1) manages to work around most quirks. It would still be a pain though, since we normally distribute a compiled version of all our units (it's a Pascal compiler, producing natively compiled code). Since this header file is necessary for the system unit on which everything else depends, we'd have to distribute the sources instead, somehow find a way to get Installer.app to ask for the location of the iPhone SDK, and then translate that header and compile/install everything. That's not really user-friendly (not for us as developers, nor for our users). Not distributing anything at all (or worse, distributing a file that may make me and them liable for copyright infringement lawsuits by Apple) is obviously even less user-friendly, hence my question to see what my options are. I'd also like to point out from a signals perspective that the contents of the sigcontext and mcontext are supposed to be opaque, and other than their size, unless you are a debugger, you should not be introspecting their contents. If you are not a debugger, then you should be trying to write your code in such a way that not even the size matters outside of libc itself to let the structures change out from under you without breaking your code, if at all possible. I have tried that when I did the initial port to Mac OS X, 5 years ago or so, and failed. The situation is currently like this: 1) an fpu exception, or sigsegv, sigbus, ... occurs 2) the OS raises a mach exception, which is then converted into a unix/ bsd signal 3) we catch the signal using a handler installed at startup of the app 4) we determine the nature of the signal and where it occurred 5) we change the context of the signal (here's where we need the structures) so that it will return to our own run time error handler. We also store the necessary information (exception nature, pc where it occurred, stack pointer at the exception time) in some register fields of the context struct (which are interpreted as parameters in the run time error handler) 6) we return from the signal handler 7) the kernel resumes execution in our run time error handler 8) we generate the appropriate language exception My initial version used some form of (sig)longjmp instead of steps 5 to 7 to hand over control to our run time system, but that does not work for fpu exceptions (at least not on PPC). The reason was that as long as you did not return from a signal handler, fpu exceptions remained disabled (well, you could re-enable them in the fpscr, but the kernel dropped them on floor as soon as they occurred again afterwards). I can't immediately find again where this happens in xnu, but if you are interested I could try to look it up again. I'm not sure what alternatives I have to convert hardware/OS exceptions into language exceptions (at least not if I want to be able to provide backtraces to the consumers of those exceptions, like we do right now). This email sent to site_archiver@lists.apple.com