November 2009 - Darwin-kernel

Re: Memory Management and 32b Range
by Duane Murphy 13 Nov '09

13 Nov '09

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: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com PGP.sig

1 0

Memory Management and 32b Range
by Duane Murphy 13 Nov '09

13 Nov '09

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: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com PGP.sig

1 0

Re: fork and exec problems
by Chuck Carlson 10 Nov '09

10 Nov '09

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: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: fork and exec problems
by Michael Smith 10 Nov '09

10 Nov '09

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: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: fork and exec problems
by Shawn Erickson 10 Nov '09

10 Nov '09

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=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=V1sYUTTqX8OhCcm3jpVSDZ+sSrg7aoiHelJE22hOp4A=; b=t3Ols1jCKdvysbwOZc8grqln63sT5glkshY2Wa3gqZcnEa+3Jts09JbWc6bSOifQ89 WFcj6GoJHxzUmHbXHIwmm6ByBbwwiwEfluWQRtUwvJOQjoHhxsDe/xFMVJYxdD7NDpoW tQEK5sBjZfMV/XuJvkEwdr6Rs48GQMNa/zvRs= 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=PZX6lw44h6h62raXk9Joj3uFOSLWFEPDtw0dA3WhrQhX3yS8/k20PvkuafSqbPd/Uk IrK7sGkDUEwaIkPdOFgtnXmgDRmbh8RsyLgDSoq3/7eqsk+PVbBbFNcj9xpF/6usLSvL BbM7KR6SGGhA0cPbg2ykYr7OpIy3MwZSZnh8Q= On Tue, Nov 10, 2009 at 9:07 AM, Chuck Carlson <chuck(a)sanna.com> wrote: > What's the best way to get a nice clean launch just like launchd would do? I would think the best to do that is to use launchd to launch your job. Various ways exist to get the job known to launchd and then to trigger the launching of your server on demand. -Shawn _______________________________________________ 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: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

fork and exec problems
by Chuck Carlson 10 Nov '09

10 Nov '09

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: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Solution: Unloading network drivers from CLI
by Godfrey van der Linden 10 Nov '09

10 Nov '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com For you network developers out there Cheers Godfrey #in your bashrc add // Wrap this in a C file and implement the sys_test macros. static void siocprotodetach(const char *name) { int sockfd; struct ifreq ifr; sockfd = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP); sys_test(sockfd, "Couldn't open a socket for the protocol detach"); bzero(&ifr, sizeof(ifr)); strncpy(ifr.ifr_name, name, sizeof(ifr.ifr_name)); sys_test(ioctl(sockfd, SIOCPROTODETACH, &ifr), "ioctl failed to detach protocol"); close(sockfd); } _______________________________________________ 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: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… So the problem was that I couldn't load and unload my development network driver. With Josh's and another's help I have found the magic incantations for successfully unloading. ifclient() { sudo ifconfig en2 inet 192.168.1.2 netmask 0xffffff002 $@; } nu() { ifclient up; } nd() { ifclient down delete; sudo ipunplumb; } // taken from xnu/sys/sockio.h these are kernel private for some reason #define SIOCPROTODETACH _IOWR('i', 81, struct ifreq) /* detach proto from interface */ This email sent to site_archiver(a)lists.apple.com

1 0

Re: Target system locks when single stepping in GDB kernel debug session
by James Shimer 10 Nov '09

10 Nov '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Nov 9, 2009, at 12:32 PM, Joe Lowe wrote: I am using GDB kernel debugging over ethernet. Whenever I single step over a function call the target system locks up and never returns to the debugger. The keyboard debug break sequence and power button do not help once in this state. The target machine has to be power cycled. Target system is a quad core intel based mac running OSX 10.5.8. The GDB version on the debugger system is "GNU gdb 6.3.50-20050815 (Apple version gdb-966) (Tue Mar 10 02:43:13 UTC 2009)", using the 10.5.8 kernel debug kit. The debugger is fully functional except for the single stepping issue. Has anyone else seen this or have any idea what might be the cause? Joe _______________________________________________ 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: http://lists.apple.com/mailman/options/darwin-kernel/jamesshimer%40mac.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: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… There are special hardware debugging tools used for debugging schedulers, In Circuit Emulation (ICE) and JTAG. With out them, I think your subject to catch 22 between debugger scheduling and your "step over" break point causing deadlock. This email sent to jamesshimer(a)mac.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Understanding Memory Descriptors
by Duane Murphy 09 Nov '09

09 Nov '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Nov 9, 2009, at 11:26 AM, Michael Smith wrote: > > On Nov 9, 2009, at 10:50 AM, Duane Murphy wrote: > >> I'm wondering if there is a way to "recover" an equivalent memory >> descriptor from a memory descriptors virtual address. > > You're stuck in "I have no handle" hell. > Nice. :-) >> Here's more detail. >> >> We use a user client interface to pass a large buffer to the kernel >> to >> read some data. This buffer is allocated in user space and passed >> into >> the user client to become the structureOutputDescriptor of the >> IOExternalMethodArguments. >> >> Due to our cross platform interface, this buffer is converted to a >> memory address and length using. The memory address is determined >> using IOMemoryDescriotor::map() and getVirtualAddress() on the >> resulting IOMemoryMap. > > Long term, you need to fix your "cross platform interface" so that > it takes a handle, not a pointer/length tuple. > > The mapping operation you are performing here is *expensive* on > every platform that splits the user/kernel virtual space, and it's > never going to be cheap. > >> Later this self same address must be used to read data from the disk. >> This is accomplished using IOMemoryDescriptor::withAddress() using >> the >> virtual address determined previously. >> >> Would this second memory descriptor be fundamentally equivalent to >> the >> first? > > Inasmuch as it describes the same range of client memory, yes. > >> Using the same addresses etc? Is there a way of making that >> happen? My fear is that this process is contributing to virtual >> memory >> fragmentation or at least not making the best use of available >> virtual >> memory. > > You're definitely contributing to fragementation of the kernel's > virtual address space when you map the original descriptor, and > doing a lot of redundant work to construct the second descriptor. > The fragmentation of memory with respect to the original request from user space seems unavoidable. Data has to be moved from the kernel into user space somehow. Is there a better way to do this operation? My concern is that constructing the second memory descriptor was also contributing to the fragmentation. >> The proper solution would, of course, be to be able to get the >> original memory descriptor to the IO routine. Unfortunately that may >> prove to be rather difficult given our cross platform engine. > > Does your "cross platform" code depend on dereferencing the pointer > it's passed to manipulate data inside the buffer? > > If not, then consider passing a pointer to the IOMemoryDescriptor > rather than the buffer. > > If it does, a common workaround is to maintain a list of currently- > active IOMemoryDescriptors on the client side, and to look back into > the list from your I/O shim to recover the IOMD. This doesn't save > you the cost of mapping the descriptor, but it does save you > constructing a second one. This lookup isn't necessarily as hard as > it seems; your client can find the I/O shim fairly easy when it's > instantiated, so it's just a matter of registering/deregistering its > list as it comes and goes... Indeed the addresses of the buffers are typically required. Thank you for the suggestion, this may prove to be a viable solution, at least in the short term. ...Duane -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.10.0 (Build 500) Charset: US-ASCII wsBVAwUBSvhzKUrg9acQ4r2CAQh/GAf+K9l9pVtzx6J7ipLXJoPVbXs8L09ctm0j O0zdmDMLxQlOblsDML896mfORKRzzVcBZGibLXK8PzXTZBJSmrIIQDqqQ9kptP7J CGmbBBPuQpZl22nzPz1PZ7TR0I2yLn73GIZGNEGc5XgMNN/QPks5CsUlsYPfIERx GxE8dX8WRs0f5zUWYdedv5SWFcI1OBTn4xzBIMSvYDlJpfd95BV85lvnsQHDztIy FrxiYiIq8qkhFqmtr7I3J/8lIFMm5M54mDNZjxLmghr8yUp5QwVHlCdmU1PYwjXA JX6TlBMUKRMgbqmcO4N+S/qEJy+cMgeP1cVJsVSJfwFwie/1u/XK6A== =wAlu -----END PGP SIGNATURE----- _______________________________________________ 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: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Understanding Memory Descriptors
by Michael Smith 09 Nov '09

09 Nov '09

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: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0