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

10.7 Kernel panic regarding HFS+ journaling
by Andrew Keller 25 Apr '17

25 Apr '17

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Handling exceptions with Mach ports
by Junker, Gregory 17 Apr '17

17 Apr '17

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AQHSt6whdBYCLvWyZ0akA2GbGcRr/qHKfn0AgAATmoA= Thread-topic: Handling exceptions with Mach ports On Mon, 2017-04-17 at 22:50 +0200, Jonas Maebe wrote: > On 17/04/17 20:55, Junker, Gregory wrote: > > > > https://gist.github.com/rodionovd/01fff61927a665d78ecf > > > > seem to suggest that returning KERN_SUCCESS should be sufficient to suppress further handling of the exception. > > > > Any thoughts or suggestions? > Maybe have a look at > https://web-beta.archive.org/web/20091230024736/http://www.brianweb.net/mis… I was basically doing what he was doing (and my actual use case is his example -- selectively unprotect regions of memory), but my test case was an actual segfault: dereferencing a null pointer, which isn't recoverable (duh, in retrospect). When I convert my test to using actual allocated/protected memory, I get the expected results (unprotect and move on). Thanks! Greg _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Handling exceptions with Mach ports
by Jonas Maebe 17 Apr '17

17 Apr '17

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 On 17/04/17 20:55, Junker, Gregory wrote: https://gist.github.com/rodionovd/01fff61927a665d78ecf seem to suggest that returning KERN_SUCCESS should be sufficient to suppress further handling of the exception. Any thoughts or suggestions? Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com Maybe have a look at https://web-beta.archive.org/web/20091230024736/http://www.brianweb.net/mis…

1 0

Handling exceptions with Mach ports
by Junker, Gregory 17 Apr '17

17 Apr '17

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AQHSt6whdBYCLvWyZ0akA2GbGcRr/g== Thread-topic: Handling exceptions with Mach ports Hi all I am trying to handle a segfault at the Mach port level (as opposed to the BSD signal level). I am doing this for a specific reason. The problem I am having is telling the kernel that I have handled the exception and that it should keep calm and carry on. Regardles whether or not I return KERN_SUCCESS from my handler, the segfault is always handled at a subsequent level and the application crashses with the normal "Segmentation Fault: 11" message. Do I need to alter the thread state before returning from my handler? Everything I have seen in the (limited) documentation and kernel source, and in examples such as this https://gist.github.com/rodionovd/01fff61927a665d78ecf seem to suggest that returning KERN_SUCCESS should be sufficient to suppress further handling of the exception. Any thoughts or suggestions? Thanks Greg _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel Panic after unloading a kext
by Prokash Sinha 14 Apr '17

14 Apr '17

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com By the way, I get the same problem when I try to Unload ( after a successful load of lognke example ). Here is the stack * thread #3: tid = 0x024b, 0xffffff7f96add500, name = '0xffffff80200ac9a8', queue = '0x0', stop reason = EXC_BAD_ACCESS (code=1, address=0x96add500) * frame #0: 0xffffff7f96add500 frame #1: 0xffffff8014df3fad kernel`sflt_initsock(so=<unavailable>) + 125 at kpi_socketfilter.c:446 [opt] frame #2: 0xffffff8014dc9c84 kernel`socreate_internal(dom=<unavailable>, aso=<unavailable>, type=<unavailable>, proto=0, p=0xffffff8020194e90, flags=0, ep=<unavailable>) + 708 at uipc_socket.c:766 [opt] frame #3: 0xffffff8014ddb071 kernel`socket_common [inlined] socreate(dom=<unavailable>, aso=<unavailable>, type=<unavailable>, proto=<unavailable>) + 37 at uipc_socket.c:827 [opt] frame #4: 0xffffff8014ddb04c kernel`socket_common(p=<unavailable>, domain=2, type=2, protocol=0, epid=105, retval=0xffffff80200f19d0, delegate=<unavailable>) + 332 at uipc_syscalls.c:264 [opt] frame #5: 0xffffff8014ddaee3 kernel`socket(p=<unavailable>, uap=<unavailable>, retval=<unavailable>) + 67 at uipc_syscalls.c:214 [opt] frame #6: 0xffffff8014e27066 kernel`unix_syscall(state=<unavailable>) + 550 at systemcalls.c:192 [opt] frame #7: 0xffffff80148a3c38 kernel`hndl_unix_scall + 216 -Prokash > On Apr 14, 2017, at 2:00 PM, Prokash Sinha <prokash(a)garlic.com> wrote: > > > i’ve a TCP and UDP filter both registering for IPv4 and IPv6. It’s that when try to unload > I get to this situation. I looked at the protocol type of the socket it is 0, meaning unspecified !. > > Not sure what may cause such a thing. > > > > > //Frame 1 > 39 > 440 while (filter) { > 441 struct socket_filter *filter_next; > 442 /* > 443 * Warning: sflt_attach_private_locked > 444 * will drop the lock > 445 */ > -> 446 sflt_attach_locked(so, filter, 0); > 447 > 448 filter_next = TAILQ_NEXT(filter, sf_protosw_next); > 449 if (filter_next) > 450 sflt_retain_locked(filter_next); > 451 > 452 /* > 453 * Warning: filt_release_locked may remove > 454 * the filter from the queue > 455 */ > 456 sflt_release_locked(filter); > 457 filter = filter_next; > 458 } > 459 } > > > > //Frame 2 > 765 /* Attach socket filters for this protocol */ > -> 766 sflt_initsock(so); > > > * thread #3: tid = 0x0244, 0xffffff7f916e0fc0, name = '0xffffff801aa19dc8', queue = '0x0', stop reason = EXC_BAD_ACCESS (code=1, address=0x916e0fc0) > frame #0: 0xffffff7f916e0fc0 > * frame #1: 0xffffff800f9f3fad kernel`sflt_initsock(so=<unavailable>) + 125 at kpi_socketfilter.c:446 [opt] > frame #2: 0xffffff800f9c9c84 kernel`socreate_internal(dom=<unavailable>, aso=<unavailable>, type=<unavailable>, proto=0, p=0xffffff801abdfe90, flags=0, ep=<unavailable>) + 708 at uipc_socket.c:766 [opt] > frame #3: 0xffffff800f9db071 kernel`socket_common [inlined] socreate(dom=<unavailable>, aso=<unavailable>, type=<unavailable>, proto=<unavailable>) + 37 at uipc_socket.c:827 [opt] > frame #4: 0xffffff800f9db04c kernel`socket_common(p=<unavailable>, domain=30, type=2, protocol=0, epid=105, retval=0xffffff801abb2040, delegate=<unavailable>) + 332 at uipc_syscalls.c:264 [opt] > frame #5: 0xffffff800f9daee3 kernel`socket(p=<unavailable>, uap=<unavailable>, retval=<unavailable>) + 67 at uipc_syscalls.c:214 [opt] > frame #6: 0xffffff800fa27066 kernel`unix_syscall(state=<unavailable>) + 550 at systemcalls.c:192 [opt] > frame #7: 0xffffff800f4a3c38 kernel`hndl_unix_scall + 216 > > General Purpose Registers: > rbx = 0x0000000000000000 <—— > rbp = 0xffffff90a82f3e40 > rsp = 0xffffff90a82f3e20 > r12 = 0xffffff80237b0cf8 > r13 = 0x0000000000000000 > r14 = 0xffffff8024184868 > r15 = 0xffffff8024184840 > rip = 0xffffff800f9f3fad kernel`sflt_initsock + 125 at kpi_socketfilter.c:448 > > > > kernel`sflt_initsock: > 0xffffff800f9f3f30 <+0>: pushq %rbp > 0xffffff800f9f3f31 <+1>: movq %rsp, %rbp > 0xffffff800f9f3f34 <+4>: pushq %r15 > 0xffffff800f9f3f36 <+6>: pushq %r14 > 0xffffff800f9f3f38 <+8>: pushq %r12 > 0xffffff800f9f3f3a <+10>: pushq %rbx > 0xffffff800f9f3f3b <+11>: movq %rdi, %r15 > 0xffffff800f9f3f3e <+14>: movq 0x18(%r15), %rax > 0xffffff800f9f3f42 <+18>: movq 0x18(%rax), %rbx > 0xffffff800f9f3f46 <+22>: movq 0x31534b(%rip), %rdi > 0xffffff800f9f3f4d <+29>: callq 0xffffff800f49f8c0 ; lck_rw_lock_shared > 0xffffff800f9f3f52 <+34>: cmpq $0x0, 0x80(%rbx) > 0xffffff800f9f3f5a <+42>: je 0xffffff800f9f400d ; <+221> at kpi_socketfilter.c:460 > 0xffffff800f9f3f60 <+48>: movq 0x315331(%rip), %rdi > 0xffffff800f9f3f67 <+55>: callq 0xffffff800f49fae0 ; lck_rw_lock_shared_to_exclusive > 0xffffff800f9f3f6c <+60>: testl %eax, %eax > 0xffffff800f9f3f6e <+62>: jne 0xffffff800f9f3f7c ; <+76> at kpi_socketfilter.c:436 > 0xffffff800f9f3f70 <+64>: movq 0x315321(%rip), %rdi > 0xffffff800f9f3f77 <+71>: callq 0xffffff800f49f9f0 ; lck_rw_lock_exclusive > 0xffffff800f9f3f7c <+76>: movq 0x80(%rbx), %rbx > 0xffffff800f9f3f83 <+83>: incl 0xf0(%rbx) > 0xffffff800f9f3f89 <+89>: testq %rbx, %rbx > 0xffffff800f9f3f8c <+92>: je 0xffffff800f9f400d ; <+221> at kpi_socketfilter.c:460 > 0xffffff800f9f3f92 <+98>: leaq 0x18dc43(%rip), %r14 ; ""lck_rw_unlock_exclusive(): lock held in mode: %d\n"@/Library/Caches/com.apple.xbs/Sources/xnu/xnu-3789.41.3/osfmk/i386/locks_i386.c:1236" > 0xffffff800f9f3f99 <+105>: nopl (%rax) > 0xffffff800f9f3fa0 <+112>: xorl %edx, %edx > 0xffffff800f9f3fa2 <+114>: movq %r15, %rdi > 0xffffff800f9f3fa5 <+117>: movq %rbx, %rsi > 0xffffff800f9f3fa8 <+120>: callq 0xffffff800f9f3a10 ; sflt_attach_locked at kpi_socketfilter.c:296 > -> 0xffffff800f9f3fad <+125>: movq (%rbx), %r12 > 0xffffff800f9f3fb0 <+128>: testq %r12, %r12 > 0xffffff800f9f3fb3 <+131>: je 0xffffff800f9f3f > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Kernel Panic after unloading a kext
by Prokash Sinha 14 Apr '17

14 Apr '17

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com i’ve a TCP and UDP filter both registering for IPv4 and IPv6. It’s that when try to unload I get to this situation. I looked at the protocol type of the socket it is 0, meaning unspecified !. Not sure what may cause such a thing. //Frame 1 39 440 while (filter) { 441 struct socket_filter *filter_next; 442 /* 443 * Warning: sflt_attach_private_locked 444 * will drop the lock 445 */ -> 446 sflt_attach_locked(so, filter, 0); 447 448 filter_next = TAILQ_NEXT(filter, sf_protosw_next); 449 if (filter_next) 450 sflt_retain_locked(filter_next); 451 452 /* 453 * Warning: filt_release_locked may remove 454 * the filter from the queue 455 */ 456 sflt_release_locked(filter); 457 filter = filter_next; 458 } 459 } //Frame 2 765 /* Attach socket filters for this protocol */ -> 766 sflt_initsock(so); * thread #3: tid = 0x0244, 0xffffff7f916e0fc0, name = '0xffffff801aa19dc8', queue = '0x0', stop reason = EXC_BAD_ACCESS (code=1, address=0x916e0fc0) frame #0: 0xffffff7f916e0fc0 * frame #1: 0xffffff800f9f3fad kernel`sflt_initsock(so=<unavailable>) + 125 at kpi_socketfilter.c:446 [opt] frame #2: 0xffffff800f9c9c84 kernel`socreate_internal(dom=<unavailable>, aso=<unavailable>, type=<unavailable>, proto=0, p=0xffffff801abdfe90, flags=0, ep=<unavailable>) + 708 at uipc_socket.c:766 [opt] frame #3: 0xffffff800f9db071 kernel`socket_common [inlined] socreate(dom=<unavailable>, aso=<unavailable>, type=<unavailable>, proto=<unavailable>) + 37 at uipc_socket.c:827 [opt] frame #4: 0xffffff800f9db04c kernel`socket_common(p=<unavailable>, domain=30, type=2, protocol=0, epid=105, retval=0xffffff801abb2040, delegate=<unavailable>) + 332 at uipc_syscalls.c:264 [opt] frame #5: 0xffffff800f9daee3 kernel`socket(p=<unavailable>, uap=<unavailable>, retval=<unavailable>) + 67 at uipc_syscalls.c:214 [opt] frame #6: 0xffffff800fa27066 kernel`unix_syscall(state=<unavailable>) + 550 at systemcalls.c:192 [opt] frame #7: 0xffffff800f4a3c38 kernel`hndl_unix_scall + 216 General Purpose Registers: rbx = 0x0000000000000000 <—— rbp = 0xffffff90a82f3e40 rsp = 0xffffff90a82f3e20 r12 = 0xffffff80237b0cf8 r13 = 0x0000000000000000 r14 = 0xffffff8024184868 r15 = 0xffffff8024184840 rip = 0xffffff800f9f3fad kernel`sflt_initsock + 125 at kpi_socketfilter.c:448 kernel`sflt_initsock: 0xffffff800f9f3f30 <+0>: pushq %rbp 0xffffff800f9f3f31 <+1>: movq %rsp, %rbp 0xffffff800f9f3f34 <+4>: pushq %r15 0xffffff800f9f3f36 <+6>: pushq %r14 0xffffff800f9f3f38 <+8>: pushq %r12 0xffffff800f9f3f3a <+10>: pushq %rbx 0xffffff800f9f3f3b <+11>: movq %rdi, %r15 0xffffff800f9f3f3e <+14>: movq 0x18(%r15), %rax 0xffffff800f9f3f42 <+18>: movq 0x18(%rax), %rbx 0xffffff800f9f3f46 <+22>: movq 0x31534b(%rip), %rdi 0xffffff800f9f3f4d <+29>: callq 0xffffff800f49f8c0 ; lck_rw_lock_shared 0xffffff800f9f3f52 <+34>: cmpq $0x0, 0x80(%rbx) 0xffffff800f9f3f5a <+42>: je 0xffffff800f9f400d ; <+221> at kpi_socketfilter.c:460 0xffffff800f9f3f60 <+48>: movq 0x315331(%rip), %rdi 0xffffff800f9f3f67 <+55>: callq 0xffffff800f49fae0 ; lck_rw_lock_shared_to_exclusive 0xffffff800f9f3f6c <+60>: testl %eax, %eax 0xffffff800f9f3f6e <+62>: jne 0xffffff800f9f3f7c ; <+76> at kpi_socketfilter.c:436 0xffffff800f9f3f70 <+64>: movq 0x315321(%rip), %rdi 0xffffff800f9f3f77 <+71>: callq 0xffffff800f49f9f0 ; lck_rw_lock_exclusive 0xffffff800f9f3f7c <+76>: movq 0x80(%rbx), %rbx 0xffffff800f9f3f83 <+83>: incl 0xf0(%rbx) 0xffffff800f9f3f89 <+89>: testq %rbx, %rbx 0xffffff800f9f3f8c <+92>: je 0xffffff800f9f400d ; <+221> at kpi_socketfilter.c:460 0xffffff800f9f3f92 <+98>: leaq 0x18dc43(%rip), %r14 ; ""lck_rw_unlock_exclusive(): lock held in mode: %d\n"@/Library/Caches/com.apple.xbs/Sources/xnu/xnu-3789.41.3/osfmk/i386/locks_i386.c:1236" 0xffffff800f9f3f99 <+105>: nopl (%rax) 0xffffff800f9f3fa0 <+112>: xorl %edx, %edx 0xffffff800f9f3fa2 <+114>: movq %r15, %rdi 0xffffff800f9f3fa5 <+117>: movq %rbx, %rsi 0xffffff800f9f3fa8 <+120>: callq 0xffffff800f9f3a10 ; sflt_attach_locked at kpi_socketfilter.c:296 -> 0xffffff800f9f3fad <+125>: movq (%rbx), %r12 0xffffff800f9f3fb0 <+128>: testq %r12, %r12 0xffffff800f9f3fb3 <+131>: je 0xffffff800f9f3f _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: How can I communicate between user/kernel programs?
by Jorgen Lundman 12 Apr '17

12 Apr '17

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-filter: OpenDKIM Filter v2.10.3 mail.lundman.net 0A1F611CFE7 Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=lundman.net; s=dkim; t=1492040933; bh=b2TNiodez76PlBGvYXXAvrl1dAVh004BocYGkIIGA7E=; h=Subject:To:References:From:Date:In-Reply-To; b=rHPzXvVnn8ZGV9NSoe+R+0y8RqAJeT2C2QtvpP3rW6ILxORUFSk7lAgEAF/KfSTm6 bPlpVZipKLJYRNG9ISwQ3zW1F2RQD4WcCrrCt9zhKRv66HbFTVDqfd9BBftLkLwsV2 Y4TPfFhpw66GEGLpaEFxdOSa4+IpMwwRcO7A7mTE= User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46 In traditional Unix this was done with ioctl(), where you would make up your own ioctl number, and struct*/length to pass to kernel, and/or have kernel fill in the data. Kernel uses copyin()/copyout() to cross the userland/kernel memory access barrier. (Not on OsX, the XNU kernel does copyin/copyout for you, on the "main" pointer passed through). So if you meant the literal string "bus_speed" and getting back an integer, it is what it was designed for, and very portable. For short queries of small to moderate size. If you mean you want to do communication at "bus speeds", then what Quinn recommends is better, for high speed and large buffers. Lund Major Tom wrote: > Hi, everyone. I'm a newbie to mac kernel. > > Recently I decided to develop a kext to support interprocess communication. > > > Let's say a user-space program sending operation string to kext. > And kext received the message and reply corresponding result to user-space > program. > > Given a real life example is that, a user-space program sending "bus_speed" > to kext. > When kext received the message, it sending the bus speed result of current > machine back to user-space program. > > Which it's a full-round communication. > > > Can anyone here figure out what mechanism should I use to do this job? > What communication mechanism should best suit in such case? > > Thanks all you guys. > :-D > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/darwin-kernel/lundman%40lundman.net > > This email sent to lundman(a)lundman.net > -- Jorgen Lundman | <lundman(a)lundman.net> Unix Administrator | +81 (0)90-5578-8500 Shibuya-ku, Tokyo | Japan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: How can I communicate between user/kernel programs?
by Quinn "The Eskimo!" 12 Apr '17

12 Apr '17

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 12 Apr 2017, at 11:16, Major Tom <i.escher(a)yahoo.com> wrote: > What communication mechanism should best suit in such case? It depends on what subsystem of the kernel you’re loading in: * For I/O Kit, you can use an I/O User Client <https://developer.apple.com/library/content/samplecode/SimpleUserClient/Int…> * For other types of KEXTs (NKE, VFS, general), a kernel control socket is a good balance between flexibility and ease of development. <https://developer.apple.com/library/content/documentation/Darwin/Conceptual…> Share and Enjoy -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

How can I communicate between user/kernel programs?
by Major Tom 12 Apr '17

12 Apr '17

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1491992392; bh=LiHISdMb+9A1/nt8Csrw+BEugIAjZPnKhFVCCgDmF5s=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=RNx/1cFiNWsg0+vr/MFz5F27NElissS0AIHpDg7cnEGsdyEvwhpi+tqDIzLOOsdMQ5JOztN+kak790D/CTmZgCqfRhOKCnaUGpGUxajKhGa9u38imizxMoSilxTsDIgbE6GTtQIRs+JF9dYOyxCSH6L13H57wnb+f8bFwVhsIbnSGulVc9XTsrrl28Yef3KtGJfEtoZUBmoYyOHNf72LHQba3M3lLErtxCf9LsLy0rUtM5siRGzkUgDRdx/rzPRXzCN+wyR+mjpCJCq4Fln6w0lEdOX5DmqVHVwLLWiMzf5quE9JYcqBmeJAogYUrklYP8OVB1DJ9LlU48sD4zEx8A== _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0