April 2002 - Darwin-kernel - lists.apple.com

Re: XNU Kernel compiling problem
by John Clark 06 Apr '02

06 Apr '02

Am Donnerstag den, 4. April 2002, um 20:08, schrieb Daniel J. Luke: Huh? Both xnu-201.19 and xnu-222 built _very_ easily for me (on my Mac OS X 10.1.3 system). Well from the the tag listed in MacOSX-CURRENT found in the Darwin 'module', I get: [localhost:/Volumes/FFS/MacOSX_CURRENT] root# cvs -z3 co -r xnu-233.1 xnu Protocol error: uncounted data discarded This occurs for a number of tags listed in that file. Such as the tag listed on the offical darwin source pages of the opensource web site: cvs -z3 co -r xnu-201-9.1 xnu Protocol error: uncounted data discarded [localhost:/Volumes/FFS/MacOSX_CURRENT] root# About the only version of xnu that I can get is with no tag indication at all. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: MacOSX signal handling
by Peter Andersen 06 Apr '02

06 Apr '02

> The program is attached. Sorry, I now learned, that one cannot use attachments in these forums. The code follows below. --- Sincerely, Peter Andersen, Mjxlner Informatics A/S <pa(a)mjolner.com> and University of Aarhus, Denmark <datpete(a)daimi.au.dk> ====================================================== #include <signal.h> #include <stdio.h> /* Compile with e.g. cc --save-temps -O3 -o sigcontext sigcontext.c Please ignore "ANSI C forbids newline in string constant" warning. */ static long signal_number; static unsigned long pc_at_signal; /* Home made signal context struct. Filled out by assembler routine */ typedef struct { int signal_number; unsigned long pc_at_signal; /* register state */ long GPR[32]; /* General registers (SP = GPR[1]) */ double FR[32]; /* Floating point registers */ double FPSCR; /* Floating point status register */ long XER; /* Fixed point exception register */ long CR; /* Condition register */ long LR; /* Link register (!=pc_at_signal) */ long CTR; /* Count register */ } signal_context; void MySignalHandler(signal_context *ctx) { char ch; printf( "\nMySignalHandler:\n"); printf( " Signal number from signal_context: %d\n", (int)ctx->signal_number); printf( " PC from signal_context: 0x%x\n", (int)ctx->pc_at_signal); printf( " The stack pointer at signal time: 0x%x\n", (int)ctx->GPR[1]); printf( "Type 'q' to quit; anything else to continue: "); ch = getchar(); if (ch=='q'){ exit(0); } else { printf("Returning from signal handler. Will continue infinite loop. Send more signals!\n"); return; /* To MySignalWrapper */ } } void MySignalWrapper(); /* written in assembler - see below */ void MySignalCatcher (long sig, /*siginfo_t*/ void *info, struct sigcontext *scp) { printf( "\nMySignalCatcher:\n"); printf( " Signal %d caught at PC=0x%x\n", (int)sig, (int)scp->sc_ir); /* Save signal number and PC in global variables */ signal_number = sig; pc_at_signal = scp->sc_ir; printf( " [returning through MySignalWrapper]\n"); scp->sc_ir = (long)&MySignalWrapper; /* go to MySignalWrapper upon return */ return; /* via system signal handler to MySignalWrapper */ } void InstallMySignalCatcher(void) { struct sigaction sa; sa.sa_flags = 0; /* SA_SIGINFO */ sigemptyset(&sa.sa_mask); sa.sa_handler = MySignalCatcher; sigaction( SIGFPE, &sa, 0); sigaction( SIGILL, &sa, 0); sigaction( SIGBUS, &sa, 0); sigaction( SIGEMT, &sa, 0); sigaction( SIGINT, &sa, 0); sigaction( SIGSEGV, &sa, 0); sigaction( SIGTRAP, &sa, 0); } int main() { register int sp; InstallMySignalCatcher(); __asm__ __volatile("mr %0,r1" : "=r" (sp)); /* read SP with some inline assembler */ printf("Stack in main: 0x%x\n", (int)sp); printf("Going into infinite loop. Send me a signal using 'kill' (or simply ^C).\n"); while (1) {}; } /* The assembler routine: */ asm(" .set linkagesize, (6*4) .set paramsize, (2*4) ; actually only one used (2 to ensure double align of FR) .set localsize, (2*4) ; signal_number, pc_at_signal .set registersize, (32*4 + 32*8 + 8 + 4 + 4 + 4 + 4) ; sizeof(signal_context) .set framesize, (((linkagesize + paramsize + localsize + registersize)+15)&-16) .set linkageoff, 0 .set paramoff, linkageoff+linkagesize .set localoff, paramoff+paramsize .set registeroff, localoff+localsize .set froff, registeroff + 4*32 .set fpscroff, froff + 8*32 .set xeroff, froff + 8 .set croff, xeroff + 4 .set lroff, croff + 4 .set ctroff, lroff + 4 .globl _MySignalWrapper _MySignalWrapper: ; entered upon return from UNIX signal handler ; Machine state is completely as when signal was raised, except for ; the instruction pointer (PC), whose original value is stored in ; global variable pc_at_signal ; create frame stwu r1,-framesize(r1) ; save registers ; general registers stw r0, registeroff+4*0(r1) ; r1 already changed. Fetch from saved location in linkage field (saved by stwu above) lwz r0, 0(r1) stw r0, registeroff+4*1(r1) ; r1 = SP stw r2, registeroff+4*2(r1) stw r3, registeroff+4*3(r1) stw r4, registeroff+4*4(r1) stw r5, registeroff+4*5(r1) stw r6, registeroff+4*6(r1) stw r7, registeroff+4*7(r1) stw r8, registeroff+4*8(r1) stw r9, registeroff+4*9(r1) stw r10, registeroff+4*10(r1) stw r11, registeroff+4*11(r1) stw r12, registeroff+4*12(r1) stw r13, registeroff+4*13(r1) stw r14, registeroff+4*14(r1) stw r15, registeroff+4*15(r1) stw r16, registeroff+4*16(r1) stw r17, registeroff+4*17(r1) stw r18, registeroff+4*18(r1) stw r19, registeroff+4*19(r1) stw r20, registeroff+4*20(r1) stw r21, registeroff+4*21(r1) stw r22, registeroff+4*22(r1) stw r23, registeroff+4*23(r1) stw r24, registeroff+4*24(r1) stw r25, registeroff+4*25(r1) stw r26, registeroff+4*26(r1) stw r27, registeroff+4*27(r1) stw r28, registeroff+4*28(r1) stw r29, registeroff+4*29(r1) stw r30, registeroff+4*30(r1) stw r31, registeroff+4*31(r1) ; Condition register mfcr r0 stw r0, croff(r1) ; Fixed point exception register mfxer r0 stw r0, xeroff(r1) ; Link register mflr r0 stw r0, lroff(r1) ; Count register mfctr r0 stw r0, ctroff(r1) ; Floating point registers - 8 byte aligned */ stfd f0, froff+8*0(r1) stfd f1, froff+8*1(r1) stfd f2, froff+8*2(r1) stfd f3, froff+8*3(r1) stfd f4, froff+8*4(r1) stfd f5, froff+8*5(r1) stfd f6, froff+8*6(r1) stfd f7, froff+8*7(r1) stfd f8, froff+8*8(r1) stfd f9, froff+8*9(r1) stfd f10, froff+8*10(r1) stfd f11, froff+8*11(r1) stfd f12, froff+8*12(r1) stfd f13, froff+8*13(r1) stfd f14, froff+8*14(r1) stfd f15, froff+8*15(r1) stfd f16, froff+8*16(r1) stfd f17, froff+8*17(r1) stfd f18, froff+8*18(r1) stfd f19, froff+8*19(r1) stfd f20, froff+8*20(r1) stfd f21, froff+8*21(r1) stfd f22, froff+8*22(r1) stfd f23, froff+8*23(r1) stfd f24, froff+8*24(r1) stfd f25, froff+8*25(r1) stfd f26, froff+8*26(r1) stfd f27, froff+8*27(r1) stfd f28, froff+8*28(r1) stfd f29, froff+8*29(r1) stfd f30, froff+8*30(r1) stfd f31, froff+8*31(r1) ; Floating point status register mffs f0 stfd f0, fpscroff(r1) ; save global variables signal_number and pc_at_signal on stack ; (in local variable section) to allow for nested signals bcl 20,31,L1$MySignalWrapper L1$MySignalWrapper: mflr r13 addis r3,r13,ha16(_signal_number-L1$MySignalWrapper) lwz r3,lo16(_signal_number-L1$MySignalWrapper)(r3) stw r3,localoff(r1) addis r3,r13,ha16(_pc_at_signal-L1$MySignalWrapper) lwz r3,lo16(_pc_at_signal-L1$MySignalWrapper)(r3) stw r3,localoff+4(r1) ; call actual handler la r3,linkagesize+paramsize(r1) ; address of signal_context on stack bl _MySignalHandler ; [we only get here if MySignalHandler returns after handling the signal] ; set link register (return address) to original pc_at_signal lwz r0,localoff+4(r1) mtlr r0 ; restore state (except link register) from stack ; general registers ; do not yet restore r0 and r1 lwz r2, registeroff+4*2(r1) lwz r3, registeroff+4*3(r1) lwz r4, registeroff+4*4(r1) lwz r5, registeroff+4*5(r1) lwz r6, registeroff+4*6(r1) lwz r7, registeroff+4*7(r1) lwz r8, registeroff+4*8(r1) lwz r9, registeroff+4*9(r1) lwz r10, registeroff+4*10(r1) lwz r11, registeroff+4*11(r1) lwz r12, registeroff+4*12(r1) lwz r13, registeroff+4*13(r1) lwz r14, registeroff+4*14(r1) lwz r15, registeroff+4*15(r1) lwz r16, registeroff+4*16(r1) lwz r17, registeroff+4*17(r1) lwz r18, registeroff+4*18(r1) lwz r19, registeroff+4*19(r1) lwz r20, registeroff+4*20(r1) lwz r21, registeroff+4*21(r1) lwz r22, registeroff+4*22(r1) lwz r23, registeroff+4*23(r1) lwz r24, registeroff+4*24(r1) lwz r25, registeroff+4*25(r1) lwz r26, registeroff+4*26(r1) lwz r27, registeroff+4*27(r1) lwz r28, registeroff+4*28(r1) lwz r29, registeroff+4*29(r1) lwz r30, registeroff+4*30(r1) lwz r31, registeroff+4*31(r1) ; Floating point registers - 8 byte aligned */ lfd f0, froff+8*0(r1) lfd f1, froff+8*1(r1) lfd f2, froff+8*2(r1) lfd f3, froff+8*3(r1) lfd f4, froff+8*4(r1) lfd f5, froff+8*5(r1) lfd f6, froff+8*6(r1) lfd f7, froff+8*7(r1) lfd f8, froff+8*8(r1) lfd f9, froff+8*9(r1) lfd f10, froff+8*10(r1) lfd f11, froff+8*11(r1) lfd f12, froff+8*12(r1) lfd f13, froff+8*13(r1) lfd f14, froff+8*14(r1) lfd f15, froff+8*15(r1) lfd f16, froff+8*16(r1) lfd f17, froff+8*17(r1) lfd f18, froff+8*18(r1) lfd f19, froff+8*19(r1) lfd f20, froff+8*20(r1) lfd f21, froff+8*21(r1) lfd f22, froff+8*22(r1) lfd f23, froff+8*23(r1) lfd f24, froff+8*24(r1) lfd f25, froff+8*25(r1) lfd f26, froff+8*26(r1) lfd f27, froff+8*27(r1) lfd f28, froff+8*28(r1) lfd f29, froff+8*29(r1) lfd f30, froff+8*30(r1) lfd f31, froff+8*31(r1) ; Floating point status register lfd f0, fpscroff(r1) mtfs f0 ; Fixed point exception register lwz r0, xeroff(r1) mtxer r0 ; Link register already set above ; Count register lwz r0, ctroff(r1) mtctr r0 ; Condition register lwz r0, croff(r1) mtcr r0 ; Finally restore r1 and r0 lwz r0, registeroff+4*0(r1) la r1, framesize(r1) ; return (to where signal was raised) blr "); _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: MacOSX signal handling
by Peter Andersen 06 Apr '02

06 Apr '02

Eric Albert wrote in reply to my original posting (http://lists.apple.com/mhonarc/unix-porting/msg00206.html) > Peter Andersen wrote: > > > Is there no way to get to the register contents (and preferably modify > > it before returning from signal handler)?? > > I'll second Peter's questions -- I'm trying to do much the same thing, and > running into exactly the same problems. I suppose I could grovel through > the kernel sources to figure out just what its private data structure is, > but that's definitely not ideal. > > I did note a message from Matt Watson on darwin-development from a bit > over a year ago that implied that a siginfo_t structure might be defined > soon...but that was before 10.0, and we still don't have them. How are > other folks dealing with ports that require intricate signal handling? Not surpricing, I fully agree (:-) I have replied the darwin-kernel list, and I am excited to hear the opinion on this matter from you darwin-kernel folks. Your reply, Eric, (the only one I got) convinced me that this was actually missing in the current API. And I too do not like to dig up the private structure from the kernel and use this (subject to change). However, a clever colleague of mine suggested a general mechanism that can be used if the signal context is polite enough (:-) to give at least the program counter for the trapping instruction. In the MacOSX case, this is just what you get (and ALL that you get!). In short the principle goes as follows: 1. Set up the usual signal handler. 2. Inside this signal handler, save the PC indicating the origin of the signal 3. Then (here comes the trick) modify the given sigcontext's PC by letting it point to a routine you supply. I call this the "wrapper". 4. Now simply return from the signal handler. Because of (3) the program continues execution at your "wrapper". But besides this different program counter, the state of the machine will be exactly as when the signal occurred. 5. Inside your "wrapper" you can now read all registers as they looked when the signal occurred. You will have to write this routine in assembler to avoid the standard C prologue to change anything before you get your hands at it. If you set up a new stack frame, you can even call a C routine to do the actual work of handling the signal (e.g. switching on the signal number, reading and/or modifying register contents). You could pass this C routine a pointer to the saved state. 6. When control returns to the wrapper, you restore all registers from the context (thus also writing back any registers that were changed inside the context by the C routine). 7. The final step is to set the return address of the wrapper to the original PC as saved by (2) and then returning to your code. This suggestion sounded so good that I have now made an implementation of it in a modified version of my original program (http://lists.apple.com/mhonarc/unix-porting/msg00206.html) The program is attached. Beware that it is only slightly tested - I have not checked all registers, condition codes etc. Also I do not know if there is more state that should be saved. But it seems to work. You can compile it in a terminal as it follows, and run it. Try hitting Control-C (which sends the SIGINT signal). As you can see I only look at the SP (=GPR1) from within the handler, but it makes its way all through the code (:-): ========== [localhost:~] % cc --save-temps -O3 -o sigcontext sigcontext.c sigcontext.c:88: warning: ANSI C forbids newline in string constant [localhost:~] % ./sigcontext Stack in main: 0xbffffa20 Going into infinite loop. Send me a signal using 'kill' (or simply ^C). ^C MySignalCatcher: Signal 2 caught at PC=0x1a58 [returning through MySignalWrapper] MySignalHandler: Signal number from signal_context: 2 PC from signal_context: 0x1a58 The stack pointer at signal time: 0xbffffa20 Type 'q' to quit; anything else to continue: Returning from signal handler. Will continue infinite loop. Send more signals! ^C MySignalCatcher: Signal 2 caught at PC=0x1a58 [returning through MySignalWrapper] MySignalHandler: Signal number from signal_context: 2 PC from signal_context: 0x1a58 The stack pointer at signal time: 0xbffffa20 Type 'q' to quit; anything else to continue: q [localhost:~] % ========== As you can see in the attachment, it requires quite a bit of assembler code to implement this. I have to save ALL registers (and not only the callee saves) since the code that the signal originates from has no knowledge of the wrapper being (magically) "called". I will test this a bit more, and will post corrections, if severe problems occur. However, as Eric and I stated initially, it seems strange why this sigcontext in darwin does not supply us with this information (saving us from trouble like this)????? --- Sincerely, Peter Andersen, Mjxlner Informatics A/S <pa(a)mjolner.com> and University of Aarhus, Denmark <datpete(a)daimi.au.dk> [demime 0.98b removed an attachment of type application/octet-stream which had a name of sigcontext.c] _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: NKE compilation question
by Justin C. Walker 05 Apr '02

05 Apr '02

On Friday, April 5, 2002, at 03:07 PM, Brian Wotring wrote: I'm trying to build my NKE using an automake/autoconf build environment, instead of pbxbuild. The build works fine, but I get the following when loading: bash-2.05# kmodload mynke kmodload: Unknown symbol _kmod_info in mynke kmodload: mynke is not a valid kernel module. bash-2.05# I'm sure this is something simple I'm missing, or not doing correctly. Can't say precisely, so it may not be simple :-}. You'll have to look hard at the output of 'pbxbuild' or ProjectBuilder when building an existing NKE, and verify that your version calls the various commands with the same (or similar) arguments. You probably already know that the linkage conventions differ for "normal" executables and kernel extensions. Another approach will be to look at your extension and an existing one (in /System/Library/Extensions) and see if there's something obvious that sticks out (using 'otool', for example). Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | When LuteFisk is outlawed | Only outlaws will have | LuteFisk *--------------------------------------*-------------------------------* _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

NKE compilation question
by Brian Wotring 05 Apr '02

05 Apr '02

I'm trying to build my NKE using an automake/autoconf build environment, instead of pbxbuild. The build works fine, but I get the following when loading: bash-2.05# kmodload mynke kmodload: Unknown symbol _kmod_info in mynke kmodload: mynke is not a valid kernel module. bash-2.05# I'm sure this is something simple I'm missing, or not doing correctly. -- Brian Wotring ( brian(a)shmoo.com ) PGP KeyID: 0x9674763D _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: XNU Kernel compiling problem
by Markus Hitter 05 Apr '02

05 Apr '02

Am Freitag den, 5. April 2002, um 03:02, schrieb John Clark: I can't even install the 'latest' darwin on the machine that I have available for such. The last Darwin installable version on that hardware, an 7500 with a G3 upgrade card OS X 10.1.3 works fine on my 7600 without any card. You need XPostFacto and the old "Startup Volume" App which came with Public Beta and one of XPostFacto's precedessors. Darwin 1.4.1 should work as well. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: XNU Kernel compiling problem
by Daniel J. Luke 05 Apr '02

05 Apr '02

On Thu, Apr 04, 2002 at 05:02:46PM -0800, John Clark wrote: > Am Donnerstag den, 4. April 2002, um 16:49, schrieb Daniel Hazelbaker: > >I have actually tried both. I tried the one on the website which > >supposedly corresponded to the current release of MacOSX. It failed, > >so I tried the latest from CVS and got the same problem. Supposedly > >anything that runs on Darwin will run on MacOSX. > > I've not tried to build anything in the Darwin project for over a year, > haven't really looked into finding some alternative method. > > Even then, the only version I have compiled to something that actually > worked was perhaps 1999 > before IOKit was blessed upon us. Since then even trying to compile that > has left off with missing > libraries, or misplaced headers, or makefiles that are broken in some > way or another. Huh? Both xnu-201.19 and xnu-222 built _very_ easily for me (on my Mac OS X 10.1.3 system). I'm not sure why people are having problems. (Obviously, trying to build 'newer' kernels is usually harder because of all the possible dependencies on other things being updated as well). -- Daniel J. Luke +========================================================+ | *---------------- dluke(a)geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: XNU Kernel compiling problem
by Jim Magee 05 Apr '02

05 Apr '02

you can run "nm -u" on the application's executable. It will list all the undefined symbols. You then have to search for the library that provides it. Typically, an executable doesn't know which library is going to provide a symbol. But you ought to look on the Darwin Developer documentation site first. There are discussions there about IOKit and Power Management (http://developer.apple.com/techpubs/macosx/Darwin/IOKit/IOKitFundamentals/ PowerMgmt/index.html). You probably would find what you need, or at least a hint, there. I'm neither an IOKit expert nor a PowerManagement API expert, so I have left those queries for others to respond. Having seen no better responses yet, I figured I would throw that out there. On Thursday, April 4, 2002, at 05:16 PM, Daniel Hazelbaker wrote: This is somewhat off subject, but might also be a way for me to solve my immediate problem of getting the ibook to run without the lid open; does anybody know of a way to get a list of all API calls and the libraries/frameworks that they are called from that an application uses? --Jim _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: XNU Kernel compiling problem
by Daniel Hazelbaker 05 Apr '02

05 Apr '02

This is somewhat off subject, but might also be a way for me to solve my immediate problem of getting the ibook to run without the lid open; does anybody know of a way to get a list of all API calls and the libraries/frameworks that they are called from that an application uses? Daniel Hazelbaker On Thursday, April 4, 2002, at 05:02 PM, John Clark wrote: Am Donnerstag den, 4. April 2002, um 16:49, schrieb Daniel Hazelbaker: I have actually tried both. I tried the one on the website which supposedly corresponded to the current release of MacOSX. It failed, so I tried the latest from CVS and got the same problem. Supposedly anything that runs on Darwin will run on MacOSX. I've not tried to build anything in the Darwin project for over a year, since I can't even install the 'latest' darwin on the machine that I have available for such. The last Darwin installable version on that hardware, an 7500 with a G3 upgrade card seems to have fallen off the map for Apple people to bother with. And of course, since my main thing does not derive from making up such deficits, I haven't really looked into finding some alternative method. Even then, the only version I have compiled to something that actually worked was perhaps 1999 before IOKit was blessed upon us. Since then even trying to compile that has left off with missing libraries, or misplaced headers, or makefiles that are broken in some way or another. At the moment I usually use the sources as a detailed document for figuring out how to work around IOKit... Perhaps there ought to be a fink project for Darwin itself. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: XNU Kernel compiling problem
by John Clark 05 Apr '02

05 Apr '02

Am Donnerstag den, 4. April 2002, um 16:49, schrieb Daniel Hazelbaker: I have actually tried both. I tried the one on the website which supposedly corresponded to the current release of MacOSX. It failed, so I tried the latest from CVS and got the same problem. Supposedly anything that runs on Darwin will run on MacOSX. I've not tried to build anything in the Darwin project for over a year, since I can't even install the 'latest' darwin on the machine that I have available for such. The last Darwin installable version on that hardware, an 7500 with a G3 upgrade card seems to have fallen off the map for Apple people to bother with. And of course, since my main thing does not derive from making up such deficits, I haven't really looked into finding some alternative method. Even then, the only version I have compiled to something that actually worked was perhaps 1999 before IOKit was blessed upon us. Since then even trying to compile that has left off with missing libraries, or misplaced headers, or makefiles that are broken in some way or another. At the moment I usually use the sources as a detailed document for figuring out how to work around IOKit... Perhaps there ought to be a fink project for Darwin itself. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0