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

Re: forward-porting
by Graham J Lee 31 May '06

31 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 31 May 2006, at 16:11, Morgan Winer wrote: Cheers, Graham. -- Graham J Lee "Oxford University's UNIX Expert" As seen in MacWorld UK http://iamleeg.blogspot.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… This email sent to site_archiver(a)lists.apple.com I'm interested in porting 10.3.9 to work on the latest Apple hardware. Don't do any of this without checking the licence agreement for Panther, but the following avenues may be available (and easier than a straight port, which probably relies on IOkit drivers which aren't in the public domain): + port Mac-on-Mac http://maconmac.bastix.net/ to 10.4, then run 10.3.9 in a MoM session + use/enhance the PPC emulation in QEMU/Q.app and run Panther thus smime.p7s

1 0

forward-porting
by Morgan Winer 31 May '06

31 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com - Morgan Winer mhw23(a)cornell.edu _______________________________________________ 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'm interested in porting 10.3.9 to work on the latest Apple hardware. Initial attempts show thats its likely something in a device driver, though which one is still beyond me. It hangs at different places, and at different times after power on. Any information (particular source files, packages even) would be of incredible help. This email sent to site_archiver(a)lists.apple.com

1 0

Re: DADiskEject and Resource Busy errors
by Dan Markarian 31 May '06

31 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.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… This email sent to site_archiver(a)lists.apple.com

1 0

DKIOCCDREADTOC ioctl() fails during debugging
by Stephen F. Booth 31 May '06

31 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.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… This email sent to site_archiver(a)lists.apple.com

1 0

Re: pthread_cancel()
by Per Mildner 31 May '06

31 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Organization: Swedish Institute of Computer Science On May 30, 2006, at 9:07 AM, Per Mildner wrote: _______________________________________________ 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… One guess would be that there are cancellation points within the thread startup code. That's why the exit_status check is there - so we know we at least get to the read() call... Yes, I realized that my theory was wrong after sending my mail. In either case pthread_cancel does not appear to be able to break all blocking calls to read. This email sent to site_archiver(a)lists.apple.com

1 0

DADiskEject and Resource Busy errors
by Stephen F. Booth 31 May '06

31 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.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… This email sent to site_archiver(a)lists.apple.com

1 0

launchd, agents and tn2083
by John Fieber 31 May '06

31 May '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com tn2083 "Daemons and Agents" is a good read. Thanks, -john _______________________________________________ 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… Something isn't quite adding up though. Early on in the note: "Agents are useful because they can do things that daemons can't, like connect to the window server". But later on in Figure 5 (a decision tree for selecting an agent launch method) is a different story where by global login items (/Library/Preferences/ loginwindow.plist) are the only option for launching an agent for every user on login that can talk to the window server. But earlier in the document, that method is described as unsupported. launchd will work, but it also attempts to launch agents for ssh logins, which fails because the window server is inaccessible. (Of course, the agent could be fixed to detect that and deal with it sensibly, but in this particular organizational context I don't have control over the code in the agent.) So, there appears to be no *supported* way, according to tn2083 Figure 5, to launch an agent with GUI for all users on login. Am I reading that right? Or is there some undocumented launchd.plist option to suppress attempting to launch in a non-gui (sshd) context? This email sent to site_archiver(a)lists.apple.com

1 0

Re: pthread_cancel()
by Matt Watson 30 May '06

30 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On May 30, 2006, at 9:07 AM, Per Mildner wrote: Thanks, matt. _______________________________________________ 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… One guess would be that there are cancellation points within the thread startup code. That's why the exit_status check is there - so we know we at least get to the read() call... In the below transcript you can see how it hangs even though it apparently gets cancelled as soon as read() gets some input. I see what you're talking about now. I'll have to take a closer look at this. This email sent to site_archiver(a)lists.apple.com

1 0

Re: pthread_cancel()
by Per Mildner 30 May '06

30 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Organization: Swedish Institute of Computer Science On May 30, 2006, at 4:54 AM, Per Mildner wrote: On May 8, 2006, at 12:59 PM, Andre-John Mas wrote: > > > On May 8, 2006, at 12:45 PM, Andre-John Mas wrote: > > > > > Could anyone tell me whether pthread_cancel() is planned to be > > > implemented properly in a future version of Darwin? From what I > > > understand the current implementation does not conform to the > > > posix implementation. > > > > > If you compile with _APPLE_C_SOURCE, _POSIX_C_SOURCE or > > _XOPEN_SOURCE, the implementation should behave as you want. > > > > Thanks. Just one question are these for my applications or for > compiling the kernel? This is when compiling user-level programs. matt. What exectly is supposed to change when setting _APPLE_C_SOURCE? I realize that this causes a new version of pthread_cancel to be called. However, the real problem is that the POSIX mandated thread cancellation points are missing, e.g. in read and write. static int exit_status = EXIT_FAILURE; void * func(void *arg) { char buf; exit_status = EXIT_SUCCESS; return NULL; } int main(void) { pthread_t t; void *retval; assert(!pthread_create(&t, NULL, func, NULL)); sleep(1); assert(!pthread_cancel(t)); assert(!pthread_join(t, &retval)); assert(PTHREAD_CANCELED == retval); calling read...called read()==1 calling read.. HANGS HERE until an additional <CR> entered wormwood2:~/sicstus/sicstus4wormwood2 perm$ _______________________________________________ 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… On 8-May-06, at 16:08 , Matt Watson wrote: As you point out, a different version of certain pthread routines is used when _APPLE_C_SOURCE is set. I can't reproduce what you are seeing. Do you have a self-contained source example exhibiting the problem? The following program works properly when built with _APPLE_C_SOURCE on 10.4.6: .. snip ... Adding a sleep before the call to pthread_cancel makes the program hang. One guess would be that there are cancellation points within the thread startup code. In the below transcript you can see how it hangs even though it apparently gets cancelled as soon as read() gets some input. wormwood2:~/sicstus/sicstus4wormwood2 perm$ uname -a Darwin wormwood2.sics.se 8.6.0 Darwin Kernel Version 8.6.0: Tue Mar 7 16:58:48 PST 2006; root:xnu-792.6.70.obj~1/RELEASE_PPC Power Macintosh powerpc wormwood2:~/sicstus/sicstus4wormwood2 perm$ cat foo.c #include <assert.h> #include <pthread.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> while (1) { ssize_t res; fprintf(stderr, "calling read..");fflush(stderr); res = read(STDIN_FILENO, &buf, 1); fprintf(stderr, ".called read()==%ld\n", (long)res);fflush(stderr); } return exit_status; } # The first <CR> below is for passing the line to shell (all this is done in bash from within xemacs) wormwood2:~/sicstus/sicstus4wormwood2 perm$ gcc -D_APPLE_C_SOURCE foo.c && ./a.out <CR> calling read.. HANGS UNTIL an additional <CR> entered wormwood2:~/sicstus/sicstus4wormwood2 perm$ gcc -D_APPLE_C_SOURCE foo.c && ./a.out <CR> <CR> This email sent to site_archiver(a)lists.apple.com

1 0

Re: pthread_cancel()
by Matt Watson 30 May '06

30 May '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On May 30, 2006, at 4:54 AM, Per Mildner wrote: This is when compiling user-level programs. matt. What exectly is supposed to change when setting _APPLE_C_SOURCE? I realize that this causes a new version of pthread_cancel to be called. However, the real problem is that the POSIX mandated thread cancellation points are missing, e.g. in read and write. #include <assert.h> #include <pthread.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> static int exit_status = EXIT_FAILURE; void * func(void *arg) { char buf; exit_status = EXIT_SUCCESS; read(STDIN_FILENO, &buf, 1); return NULL; } int main(void) { pthread_t t; void *retval; assert(!pthread_create(&t, NULL, func, NULL)); assert(!pthread_cancel(t)); assert(!pthread_join(t, &retval)); assert(PTHREAD_CANCELED == retval); return exit_status; } _______________________________________________ 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… On 8-May-06, at 16:08 , Matt Watson wrote: On May 8, 2006, at 12:59 PM, Andre-John Mas wrote: > > > On May 8, 2006, at 12:45 PM, Andre-John Mas wrote: > > > > > Could anyone tell me whether pthread_cancel() is planned to be > > > implemented properly in a future version of Darwin? From what I > > > understand the current implementation does not conform to the > > > posix implementation. > > > > > If you compile with _APPLE_C_SOURCE, _POSIX_C_SOURCE or > > _XOPEN_SOURCE, the implementation should behave as you want. > > > > Thanks. Just one question are these for my applications or for > compiling the kernel? As you point out, a different version of certain pthread routines is used when _APPLE_C_SOURCE is set. I can't reproduce what you are seeing. Do you have a self-contained source example exhibiting the problem? The following program works properly when built with _APPLE_C_SOURCE on 10.4.6: This email sent to site_archiver(a)lists.apple.com

1 0