June 2006 - Darwin-kernel - lists.apple.com

Re: cross-bounday memory communication b/w user app and the Kernel.How?
by rohit dhamija 06 Jun '06

06 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=T0k4meNW2+TA8RY+clBtkYsSYHd3PdsAfan1VJolbe5fZHaOWQKXntMOI1XekCNmp6SbJGx0oxxVpo6M7oGFu+nJjYnaZUqHOyvN147DMWRBpjytzRMJxei/LTEbgKx8aRIBJajmfS3bupr/mLCKmUCdYGCz6fo/6AVfe1R8/Ds= Hi, Thanks for your reply. With help of the experts, I have finally able to do cross boundary communication successfully. Below is the code snippet for your review. As per Terrys and Michael comments, I have allocated the Command packet memory dynamically and the response packet is kept statically allocated. Shared Structure: ================= typedef struct { unsigned long CmdSize; // Size of command parameters unsigned char InstCode; // Opcode part of CmdCode (set by driver) } CMD_HEAD, *PCMD_HEAD; typedef struct { unsigned long RspSize; // Size of data returned unsigned char ErrorInfo; // Error information } RSP_HEAD, *PRSP_HEAD; typedef union _IOCTL_COMMAND { PCMD_HEAD pApiCmd;// Pointer to Command head RSP_HEAD ApiRsp; // Response head buffer } IOCTL_COMMAND , *PIOCTL_COMMAND; typedef struct { unsigned long pIndex; //the index required by GetDeviceInfo unsigned long iBufferSz; //The command Sz unsigned long oBufferSz; //the expected output Buffer size IOCTL_COMMAND IOCmd; } COMMAND_EXCHANGE, *PCOMMAND_EXCHANGE; At Application Layer: ===================== // assign the input buffer to structIn structIn.IOCmd.pApiCmd = iBuffer; // iBuffer is the void* buffer // Struct Input and Structure output kernReturn = IOConnectMethodStructureIStructureO(*dataPort, myDriverAPICommand, inBuffSize, &outBuffSize, &structIn, &structOut); // copy the output data in oBuffer memcpy(oBuffer, &(structOut.IOCmd.ApiRsp) , oBufferSize); At KEXT Layer: ============= In IOUserClient class: IOReturn myDriverUserClient::CommonAPICmd( COMMAND_EXCHANGE* inpkt, COMMAND_EXCHANGE* outpkt){ PCMD_HEAD pCmd = NULL; PRSP_HEAD pRsp = NULL; pCmd = (PCMD_HEAD)IOMalloc(inputSize); pRsp = (PRSP_HEAD)&(inpkt->IOCmd.ApiRsp); if( (pCmd == NULL) || (pRsp == NULL)) { DBLog(("\nMemory could not be allocated\n")); return kIOReturnNoResources; } status = copyin( (user_addr_t) inpkt->IOCmd.pApiCmd, pCmd, inputSize); .. .. } Bulk communication Module: ========================= In IOService: And then pass the command info to the BULK Communication module: bulkDeviceCommuncation() { IOReturn status; UInt32 size; IOMemoryDescriptor *memDescOut = NULL; IOMemoryDescriptor *memDescIn = NULL; // Validate and allocate if (myDataStructure->fOutPipe == NULL) { status = kIOReturnNoDevice; goto out; } if ((memDescOut = IOMemoryDescriptor::withAddress(&Command, sizeof(COMMAND), kIODirectionOut) == NULL) { status = kIOReturnNoMemory; goto out; } if ((memDescIn = IOMemoryDescriptor::withAddress(&Response, sizeof(RESPONSE), kIODirectinIn) == NULL) { status = kIOReturnNoMemory; goto out; } // do outbound command if ((status = memDescOut->prepare()) != kIOReturnSuccess) goto out; status = myDataStructure->fOutPipe->Write(memDescOut, 1000, 2000, sizeof(COMMAND), NULL); memDescOut->complete(); if (status != kIOReturnSuccess) goto out; // do inbound response if ((status = memDescIn->prepare()) != kIOReturnSuccess) goto out; status = myDataStructure->fInPipe->Read(memDescIn, 1000, 2000, size, NULL, &size); memDescIn->complete(); out: if (memDescOut) memDescOut->release(); if (memDescIn) memDescIn->release(); return(status); } Please send your comments for the same. Thanks and Regards, Rohit Dhamija Michael Smith writes: > > On Jun 5, 2006, at 7:52 AM, Andrew Gallatin wrote: > > > I'm simply trying to account for why it takes ~8x as long for a simple > > syscall, > > Which "simple" syscall? I think lmbench uses getppid for its null syscall. Sure, you could hack getppid to run like a bat out of hell, but, as I mentioned in a different branch of this thread, what I really care about is getting into (and out of) the ioctl handler for my driver quickly. I have a hacked version of lmbench which measures this, but that's pretty hard to duplicate. See my original email from 2004 about this: http://lists.apple.com/archives/Darwin-kernel/2004/Jun/msg00099.html > > and ~4x as long to get an ioctl into our driver when running > > MacOSX vs ppc64 linux on the same hardware. On x86 linux, when > > switching from the 1G/3G split to 4G/4G, we see a similar bloat of > > ioctl times. I had simply assumed that the 4G address space was the > > issue. Perhaps more of the blame lies elsewhere. > > Syscall entry/exit is certainly more expensive on Mac OS than Linux. > It comprises such a miniscule part of the elapsed system time on > typical systems that whilst it shows up a lot on micro-benchmarks, > it's not a very rewarding target for optimisation. Our software needs a way to (quickly) request our driver pin and send (or receive) data from some large buffer. The longer this takes, the less efficient HPC computations are. Drew _______________________________________________ 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/rohit.dhamija%40gmail.… This email sent to rohit.dhamija(a)gmail.com -- Rohit Dhamija(M) 9818446545 _______________________________________________ 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.… On 6/6/06, Andrew Gallatin <gallatin(a)cs.duke.edu> wrote: This email sent to site_archiver(a)lists.apple.com

1 0

Re: cross-bounday memory communication b/w user app and the Kernel.How?
by Andrew Gallatin 05 Jun '06

05 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Michael Smith writes: > > On Jun 5, 2006, at 7:52 AM, Andrew Gallatin wrote: > > > I'm simply trying to account for why it takes ~8x as long for a simple > > syscall, > > Which "simple" syscall? I think lmbench uses getppid for its null syscall. Sure, you could hack getppid to run like a bat out of hell, but, as I mentioned in a different branch of this thread, what I really care about is getting into (and out of) the ioctl handler for my driver quickly. I have a hacked version of lmbench which measures this, but that's pretty hard to duplicate. See my original email from 2004 about this: http://lists.apple.com/archives/Darwin-kernel/2004/Jun/msg00099.html > > and ~4x as long to get an ioctl into our driver when running > > MacOSX vs ppc64 linux on the same hardware. On x86 linux, when > > switching from the 1G/3G split to 4G/4G, we see a similar bloat of > > ioctl times. I had simply assumed that the 4G address space was the > > issue. Perhaps more of the blame lies elsewhere. > > Syscall entry/exit is certainly more expensive on Mac OS than Linux. > It comprises such a miniscule part of the elapsed system time on > typical systems that whilst it shows up a lot on micro-benchmarks, > it's not a very rewarding target for optimisation. Our software needs a way to (quickly) request our driver pin and send (or receive) data from some large buffer. The longer this takes, the less efficient HPC computations are. Drew _______________________________________________ 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: cross-bounday memory communication b/w user app and the Kernel.(Solved)
by rohit dhamija 05 Jun '06

05 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=CY4KTN3MSFbLBpqKUIbiYi3dTk4qwdZzeCCNN+ZtLeCxVdYnCpA00o/7SdQFeWCRT9N9Nq+9C0RKjA20N88Ey9DIbBdEe6xSFIvEMKno1p2wRYTOZfQubvcM6PpiMWmpaNcp04An1Gjdhoc4ANGsYn/2yEGJHLZUExu9xKn5K04= Hi, Thanks for your reply. With help of the experts, I have finally able to do cross boundary communication successfully. Below is the code snippet for your review. As per Terrys and Michael comments, I have allocated the Command packet memory dynamically and the response packet is kept statically allocated. Shared Structure: ================= typedef struct { unsigned long CmdSize; // Size of command parameters unsigned char InstCode; // Opcode part of CmdCode (set by driver) } CMD_HEAD, *PCMD_HEAD; typedef struct { unsigned long RspSize; // Size of data returned unsigned char ErrorInfo; // Error information } RSP_HEAD, *PRSP_HEAD; typedef union _IOCTL_COMMAND { PCMD_HEAD pApiCmd;// Pointer to Command head RSP_HEAD ApiRsp; // Response head buffer } IOCTL_COMMAND , *PIOCTL_COMMAND; typedef struct { unsigned long pIndex; //the index required by GetDeviceInfo unsigned long iBufferSz; //The command Sz unsigned long oBufferSz; //the expected output Buffer size IOCTL_COMMAND IOCmd; } COMMAND_EXCHANGE, *PCOMMAND_EXCHANGE; At Application Layer: ===================== // assign the input buffer to structIn structIn.IOCmd.pApiCmd = iBuffer; // iBuffer is the void* buffer // Struct Input and Structure output kernReturn = IOConnectMethodStructureIStructureO(*dataPort, myDriverAPICommand, inBuffSize, &outBuffSize, &structIn, &structOut); // copy the output data in oBuffer memcpy(oBuffer, &(structOut.IOCmd.ApiRsp) , oBufferSize); At KEXT Layer: ============= In IOUserClient class: IOReturn myDriverUserClient::CommonAPICmd( COMMAND_EXCHANGE* inpkt, COMMAND_EXCHANGE* outpkt){ PCMD_HEAD pCmd = NULL; PRSP_HEAD pRsp = NULL; pCmd = (PCMD_HEAD)IOMalloc(inputSize); pRsp = (PRSP_HEAD)&(inpkt->IOCmd.ApiRsp); if( (pCmd == NULL) || (pRsp == NULL)) { DBLog(("\nMemory could not be allocated\n")); return kIOReturnNoResources; } status = copyin( (user_addr_t) inpkt->IOCmd.pApiCmd, pCmd, inputSize); .. .. } Bulk communication Module: ========================= In IOService: And then pass the command info to the BULK Communication module: bulkDeviceCommuncation() { IOReturn status; UInt32 size; IOMemoryDescriptor *memDescOut = NULL; IOMemoryDescriptor *memDescIn = NULL; // Validate and allocate if (myDataStructure->fOutPipe == NULL) { status = kIOReturnNoDevice; goto out; } if ((memDescOut = IOMemoryDescriptor::withAddress(&Command, sizeof(COMMAND), kIODirectionOut) == NULL) { status = kIOReturnNoMemory; goto out; } if ((memDescIn = IOMemoryDescriptor::withAddress(&Response, sizeof(RESPONSE), kIODirectinIn) == NULL) { status = kIOReturnNoMemory; goto out; } // do outbound command if ((status = memDescOut->prepare()) != kIOReturnSuccess) goto out; status = myDataStructure->fOutPipe->Write(memDescOut, 1000, 2000, sizeof(COMMAND), NULL); memDescOut->complete(); if (status != kIOReturnSuccess) goto out; // do inbound response if ((status = memDescIn->prepare()) != kIOReturnSuccess) goto out; status = myDataStructure->fInPipe->Read(memDescIn, 1000, 2000, size, NULL, &size); memDescIn->complete(); out: if (memDescOut) memDescOut->release(); if (memDescIn) memDescIn->release(); return(status); } Please send your comments for the same. Thanks and Regards, Rohit Dhamija _______________________________________________ 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: cross-bounday memory communication b/w user app and the Kernel.How?
by Michael Smith 05 Jun '06

05 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jun 5, 2006, at 7:52 AM, Andrew Gallatin wrote: I'm simply trying to account for why it takes ~8x as long for a simple syscall, Which "simple" syscall? and ~4x as long to get an ioctl into our driver when running MacOSX vs ppc64 linux on the same hardware. On x86 linux, when switching from the 1G/3G split to 4G/4G, we see a similar bloat of ioctl times. I had simply assumed that the 4G address space was the issue. Perhaps more of the blame lies elsewhere. = Mike _______________________________________________ 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.… Syscall entry/exit is certainly more expensive on Mac OS than Linux. It comprises such a miniscule part of the elapsed system time on typical systems that whilst it shows up a lot on micro-benchmarks, it's not a very rewarding target for optimisation. This email sent to site_archiver(a)lists.apple.com

1 0

Re: cross-bounday memory communication b/w user app and the Kernel.How?
by Andrew Gallatin 05 Jun '06

05 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Michael Smith writes: > > On Jun 2, 2006, at 12:45 PM, Andrew Gallatin wrote: > > > Terry Lambert writes: > >> are different address spaces. Unlike most 32 bit OS's intended to > >> operate on small machines, MacOS X does not map the user process > >> address space into the kernel address space, so a direct copy is not > >> possible for a user space buffer when you are operating in kernel > >> space (or vice versa - which is not possible even on OS's that map > >> process in, since they don't map the kernel out into user land). The > >> benefit of doing this is that instead of having only 2G or 3G for > >> your > >> programs, you get the full 4G. It also means that instead of only > >> having 2G or 1G for the kernel's use, you have the full 4G - that > >> effectively means that the kernel can do a lot more housekeeping in > >> its own memory, and can theerefore run on machines with large amounts > >> of physical memory (8G, 16G, etc.) without running out of address > >> space. > > > > The downside of this is that things like syscalls take about 8x long > > as linux on the same hardware the last time I measured them. > > The 4/4 split does not noticeably affect the speed of system calls. > > It does, however, make it possible to run applications on datasets > that you could not otherwise run, and to support hardware that you > could not otherwise support. Again, something of a tradeoff in the > name of usefulness. > > I'm curious as to your measurement methodology, by the way. I have > seen very different numbers from a very reliable source. I'm simply trying to account for why it takes ~8x as long for a simple syscall, and ~4x as long to get an ioctl into our driver when running MacOSX vs ppc64 linux on the same hardware. On x86 linux, when switching from the 1G/3G split to 4G/4G, we see a similar bloat of ioctl times. I had simply assumed that the 4G address space was the issue. Perhaps more of the blame lies elsewhere. Drew _______________________________________________ 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: GNU-Darwin: missing code in Darwin
by proclus＠gnu-darwin.org 04 Jun '06

04 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Notably the AppleACPIPlatform driver is another piece of code that should be added to the list of things that Apple has not yet released. That is the main point of the message. Regards, proclus http://www.gnu-darwin.org/ -- Visit proclus realm! http://proclus.tripod.com/ -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GMU/S d+@ s: a+ C++++ UBULI++++$ P+ L+++(++++) E--- W++ N- !o K- w--- !O M++@ V-- PS+++ PE Y+ PGP-- t+++(+) 5+++ X+ R tv-(--)@ b !DI D- G e++++ h--- r+++ y++++ ------END GEEK CODE BLOCK------ _______________________________________________ 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 pgpsdJJdwtAHR.pgp

1 0

Re: GNU-Darwin: missing code in Darwin
by proclus＠gnu-darwin.org 04 Jun '06

04 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 4 Jun, Erik Paulson wrote: > "Apple has not said anything as to when or if most current xnu code for x86 > will be available." Notably the AppleACPIPlatform driver is another piece of code that should be added to the list of things that Apple has not yet released. That is the main point of the message. Regards, proclus http://www.gnu-darwin.org/ -- Visit proclus realm! http://proclus.tripod.com/ -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GMU/S d+@ s: a+ C++++ UBULI++++$ P+ L+++(++++) E--- W++ N- !o K- w--- !O M++@ V-- PS+++ PE Y+ PGP-- t+++(+) 5+++ X+ R tv-(--)@ b !DI D- G e++++ h--- r+++ y++++ ------END GEEK CODE BLOCK------ _______________________________________________ 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 pgpvHMnPTmldi.pgp

1 0

Fwd: Re: GNU-Darwin: missing code in Darwin
by proclus＠gnu-darwin.org 03 Jun '06

03 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com ------ Forwarded message ------ From: proclus(a)gnu-darwin.org Subject: Re: GNU-Darwin: missing code in Darwin Date: Sat, 3 Jun 2006 16:10:02 -0400 (EDT) To: proclus(a)gnu-darwin.org Cc: gnu-darwin-ports(a)lists.sourceforge.net, gnu-darwin-distribution(a)lists.sourceforge.net Sorry if you get more than one copy of this message. I found another problem with the Darwin source code repositories. AppleACPIPlatform is missing, without which it is impossible to build a free and open source operating system that boots. Could you please release this source code under the APSL agreement. Thank you. Everything else is certifiably a free software and open source OS up to Darwin-8.3. Thank you for your excellent progress. BTW, I am making good progress as well with the system. Here are some links, if you are interested. http://sourceforge.net/forum/forum.php?forum_id=576137 http://www.gnu-darwin.org/today.png Regards, Michael L. Love Ph.D Department of Biophysics and Biophysical Chemistry School of Medicine Johns Hopkins University 725 N. Wolfe Street Room 608B WBSB Baltimore MD 21205-2185 Interoffice Mail: 608B WBSB, SoM office: 410-614-2267 lab: 410-614-3179 fax: 410-502-6910 cell: 443-824-3451 http://www.gnu-darwin.org/ -- Visit proclus realm! http://proclus.tripod.com/ -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GMU/S d+@ s: a+ C++++ UBULI++++$ P+ L+++(++++) E--- W++ N- !o K- w--- !O M++@ V-- PS+++ PE Y+ PGP-- t+++(+) 5+++ X+ R tv-(--)@ b !DI D- G e++++ h--- r+++ y++++ ------END GEEK CODE BLOCK------ _______________________________________________ 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 pgp4aZf33nzLA.pgp

1 0

Re: cross-bounday memory communication b/w user app and the Kernel.How?
by Michael Smith 03 Jun '06

03 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jun 2, 2006, at 12:45 PM, Andrew Gallatin wrote: The downside of this is that things like syscalls take about 8x long as linux on the same hardware the last time I measured them. The 4/4 split does not noticeably affect the speed of system calls. = Mike _______________________________________________ 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.… Terry Lambert writes: are different address spaces. Unlike most 32 bit OS's intended to operate on small machines, MacOS X does not map the user process address space into the kernel address space, so a direct copy is not possible for a user space buffer when you are operating in kernel space (or vice versa - which is not possible even on OS's that map process in, since they don't map the kernel out into user land). The benefit of doing this is that instead of having only 2G or 3G for your programs, you get the full 4G. It also means that instead of only having 2G or 1G for the kernel's use, you have the full 4G - that effectively means that the kernel can do a lot more housekeeping in its own memory, and can theerefore run on machines with large amounts of physical memory (8G, 16G, etc.) without running out of address space. It does, however, make it possible to run applications on datasets that you could not otherwise run, and to support hardware that you could not otherwise support. Again, something of a tradeoff in the name of usefulness. I'm curious as to your measurement methodology, by the way. I have seen very different numbers from a very reliable source. This email sent to site_archiver(a)lists.apple.com

1 0

Re: cross-bounday memory communication b/w user app and the Kernel.How?
by Andrew Gallatin 02 Jun '06

02 Jun '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Terry Lambert writes: > are different address spaces. Unlike most 32 bit OS's intended to > operate on small machines, MacOS X does not map the user process > address space into the kernel address space, so a direct copy is not > possible for a user space buffer when you are operating in kernel > space (or vice versa - which is not possible even on OS's that map > process in, since they don't map the kernel out into user land). The > benefit of doing this is that instead of having only 2G or 3G for your > programs, you get the full 4G. It also means that instead of only > having 2G or 1G for the kernel's use, you have the full 4G - that > effectively means that the kernel can do a lot more housekeeping in > its own memory, and can theerefore run on machines with large amounts > of physical memory (8G, 16G, etc.) without running out of address space. The downside of this is that things like syscalls take about 8x long as linux on the same hardware the last time I measured them. Drew _______________________________________________ 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