August 2010 - Darwin-kernel

Re: Getting Physical address of a buffer
by chas williams - CONTRACTOR 09 Aug '10

09 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Mon, 9 Aug 2010 11:38:54 -0700 shailesh jain <coolworldofshail(a)gmail.com> wrote: > @Mike - There are many instances where you will need physical > addresses. Let me point out couple of them. > > - Memory ballooning is a technique where in guest driver allocates > pages in the guest and passes down PPNs to the hypervisor. Hypervisor > takes this pages and gives it to another Virtual machine for its use. > Hypervisor does Physical address to Machine address (actual address in > Physical ram. w/o virtualization you would call this Physical address) > mapping. well you really dont need the physical addresses for these pages. you just need a mechanism to map the same physical range to multiple virtual ranges. you should probably be looking at the mach vm_* calls. > - Hypervisor wants to do fast IO - i.e read/write from/to guest memory > directly. Again you need physical address (different from Machine > address.) cpu's generally do not operate on physical (or machine) addresses. they generally go through your page mapper. so even if you have the physical address, you will need to map it at some point so the hypervisor can actually do something with the memory. although, i suppose one could be passing around buffers from a driver but the driver would handle the virtual/physical issue. > @Terry - Things are all good only when you have OS being the bottom > most layer (you have EFI et all, but still) . With virtualization - > you have Hypervisor underneath. Things are complicated then. > > > > Shailesh Jain > > > > > > > > On Sat, Aug 7, 2010 at 2:42 PM, James C > <james.from.wellington(a)gmail.com> wrote: > > Hi Terry and Shailesh, > > > > Re (4) below, hypothetically, could that include de-powering only > > some parts of physical memory, when they're not needed? > > > > Shailesh, you know that the physical memory isn't contiguous. What > > would you think of being given the physical address of the first > > 0-byte segment? Why would that not meet your needs? > > > > Regards, > > James. > > > >> Message: 4 > >> Date: Fri, 6 Aug 2010 20:43:42 -0700 > >> From: Terry Lambert <tlambert(a)apple.com> > >> Subject: Re: Getting Physical address of a buffer > >> To: shailesh jain <coolworldofshail(a)gmail.com> > >> Cc: darwin-kernel(a)lists.apple.com > >> Message-ID: <EC5425AB-CC65-4CF5-AFFA-1A015ED530B6(a)apple.com> > >> Content-Type: text/plain; charset=us-ascii > >> > >> This question gets asked every once in a while: "why do I have to > >> use OS routines to talk to hardware?". > >> > >> The basic answer is that there's virtual memory, there's wired > >> memory, and then there's physical memory, and all three aren't the > >> same thing. > >> > >> There are several reasons that an OS that runs its kernel in a > >> virtual address space doesn't want to give you physical address > >> information directly; let's briefly hit the top four on my > >> personal top ten list: > >> > > <snip> > >> (4) The OS likes to be kept informed of information for its own > >> reasons so it can play tricks behind your back > >> > >> The tricks themselves don't matter, what matters is that you > >> enable performance and power management winds by following the > >> rules; if you don't follow the rules, and try to avoid the OS > >> interfaces, you also avoid the OS signaling mechanisms that are > >> used to implement these optimization. Unfortunately for you, this > >> is like declaring a variable that is modified out of scope, and > >> not marking it volatile: failure to notify the OS of the nature of > >> your access means the OS gets to do any optimization it wants. > >> For a volatile variable, that may mean not exiting the work loop > >> when the signal handler fires. For a device driver, it generally > >> means a panic in the driver. > >> > >> -- Terry > > _______________________________________________ > > 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/coolworldofshail%40gma… > > > > This email sent to coolworldofshail(a)gmail.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: Getting Physical address of a buffer
by shailesh jain 09 Aug '10

09 Aug '10

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:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1y0sjYe3ERW0OaoADNuFTTLBh60eGVqJBXy8yJMhRls=; b=j62hk79ZUPriTA3FQ+72b0kQ7I31fVMK1e7etzmPBYiMMOyXES4qK0KrJNH1pskAYb gEUmHFEazu7WKby0tkeDtJJoLX9UXgYny1YibTkRm2zygccXBIiflOaEa0Z4dffWGAL7 58WrfyCOOBZfIa8wN8BrxsdSKQ3zT62TwOSHk= 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:content-transfer-encoding; b=OgX+js3OrumYs0tiec2xNhxcnaP5U+z7FqAlgYsCT5qEwzl4gvDPQluwcjlcRyfZ1G hKJo6DZ5Iwn40qWHU5tDzLB9SnDi0oyXpXlwPNIpL7Vkto1iAVuCXPr3+ZiYYLDqILcA yxr+f9C074y3ItjHdED5RR9boQzH6slsDVSZM= @Mike - There are many instances where you will need physical addresses. Let me point out couple of them. - Memory ballooning is a technique where in guest driver allocates pages in the guest and passes down PPNs to the hypervisor. Hypervisor takes this pages and gives it to another Virtual machine for its use. Hypervisor does Physical address to Machine address (actual address in Physical ram. w/o virtualization you would call this Physical address) mapping. - Hypervisor wants to do fast IO - i.e read/write from/to guest memory directly. Again you need physical address (different from Machine address.) @Terry - Things are all good only when you have OS being the bottom most layer (you have EFI et all, but still) . With virtualization - you have Hypervisor underneath. Things are complicated then. Shailesh Jain On Sat, Aug 7, 2010 at 2:42 PM, James C <james.from.wellington(a)gmail.com> wrote: > Hi Terry and Shailesh, > > Re (4) below, hypothetically, could that include de-powering only some > parts of physical memory, when they're not needed? > > Shailesh, you know that the physical memory isn't contiguous. What > would you think of being given the physical address of the first > 0-byte segment? Why would that not meet your needs? > > Regards, > James. > >> Message: 4 >> Date: Fri, 6 Aug 2010 20:43:42 -0700 >> From: Terry Lambert <tlambert(a)apple.com> >> Subject: Re: Getting Physical address of a buffer >> To: shailesh jain <coolworldofshail(a)gmail.com> >> Cc: darwin-kernel(a)lists.apple.com >> Message-ID: <EC5425AB-CC65-4CF5-AFFA-1A015ED530B6(a)apple.com> >> Content-Type: text/plain; charset=us-ascii >> >> This question gets asked every once in a while: "why do I have to use OS routines to talk to hardware?". >> >> The basic answer is that there's virtual memory, there's wired memory, and then there's physical memory, and all three aren't the same thing. >> >> There are several reasons that an OS that runs its kernel in a virtual address space doesn't want to give you physical address information directly; let's briefly hit the top four on my personal top ten list: >> > <snip> >> (4) The OS likes to be kept informed of information for its own reasons so it can play tricks behind your back >> >> The tricks themselves don't matter, what matters is that you enable performance and power management winds by following the rules; if you don't follow the rules, and try to avoid the OS interfaces, you also avoid the OS signaling mechanisms that are used to implement these optimization. Unfortunately for you, this is like declaring a variable that is modified out of scope, and not marking it volatile: failure to notify the OS of the nature of your access means the OS gets to do any optimization it wants. For a volatile variable, that may mean not exiting the work loop when the signal handler fires. For a device driver, it generally means a panic in the driver. >> >> -- Terry > _______________________________________________ > 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/coolworldofshail%40gma… > > This email sent to coolworldofshail(a)gmail.com > -- Shailesh Jain _______________________________________________ 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: Getting Physical address of a buffer
by James C 07 Aug '10

07 Aug '10

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:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=n5fGI1TwvFiW2lg6+e8oLPKmJ2m/xK1lV6SoUmiVeIs=; b=TUPiYbjFcC0LAHwbAx1ZabWk2BmncemeLFe1373FlXNFoCZcwcvSKyu12Ev/7jnSPV m88e4JjKY9gcbb/EtcssaLlh7iawNs2XV7//L4+Zh2XvezcKR7NZghHq8hP2BZd/P8wM /oGxhD3C9B6fSo4gCOy+lpjmdQsk9knzdxh1o= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=E91GY7NE789l1p8rdEX+VynEgG2F5dBM3XLuJJ62qD8d5d85BhlBYFPbancXNzRLee aPgVXlw7zP1H9eVLVQHhWWka39oO7lHdgrc7W8KTCgxHvWvvEXvaRF0wMByfNF0VgJ2B retsLJc/Yqjp0DTdIacSUAixIw7paZK+H82kg= Hi Terry and Shailesh, Re (4) below, hypothetically, could that include de-powering only some parts of physical memory, when they're not needed? Shailesh, you know that the physical memory isn't contiguous. What would you think of being given the physical address of the first 0-byte segment? Why would that not meet your needs? Regards, James. > Message: 4 > Date: Fri, 6 Aug 2010 20:43:42 -0700 > From: Terry Lambert <tlambert(a)apple.com> > Subject: Re: Getting Physical address of a buffer > To: shailesh jain <coolworldofshail(a)gmail.com> > Cc: darwin-kernel(a)lists.apple.com > Message-ID: <EC5425AB-CC65-4CF5-AFFA-1A015ED530B6(a)apple.com> > Content-Type: text/plain; charset=us-ascii > > This question gets asked every once in a while: "why do I have to use OS routines to talk to hardware?". > > The basic answer is that there's virtual memory, there's wired memory, and then there's physical memory, and all three aren't the same thing. > > There are several reasons that an OS that runs its kernel in a virtual address space doesn't want to give you physical address information directly; let's briefly hit the top four on my personal top ten list: > <snip> > (4) The OS likes to be kept informed of information for its own reasons so it can play tricks behind your back > > The tricks themselves don't matter, what matters is that you enable performance and power management winds by following the rules; if you don't follow the rules, and try to avoid the OS interfaces, you also avoid the OS signaling mechanisms that are used to implement these optimization. Unfortunately for you, this is like declaring a variable that is modified out of scope, and not marking it volatile: failure to notify the OS of the nature of your access means the OS gets to do any optimization it wants. For a volatile variable, that may mean not exiting the work loop when the signal handler fires. For a device driver, it generally means a panic in the driver. > > -- Terry _______________________________________________ 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: Getting Physical address of a buffer
by Terry Lambert 07 Aug '10

07 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com This question gets asked every once in a while: "why do I have to use OS routines to talk to hardware?". The basic answer is that there's virtual memory, there's wired memory, and then there's physical memory, and all three aren't the same thing. There are several reasons that an OS that runs its kernel in a virtual address space doesn't want to give you physical address information directly; let's briefly hit the top four on my personal top ten list: (1) It doesn't want you to depend on the physical page backing a virtual page not being moved on you Hypothetical situation: suppose you had a device that needed access to a contiguous region of physical memory; for our example, we'll use a Buslogic/Bustek-848 video capture card, which effectively needs to stream into a contiguous region of physical memory because it not only doesn't have enough memory on board for this, it also doesn't have the memory to manage a descriptor pool for your memory in order to do scatter/gather, and it's simpler if it forces you to a page alignment, and so on. Now you want the video capture card to have that memory, but over time, physical memory in computers becomes fragmented due to how long an allocation can live being wildly variant per memory consumer. What are your choices? Most OS's pick option (A): (a) Load the/a driver at boot time, and allocate a large physical chunk before memory becomes fragmented; make that memory unavailable for use by the OS, even though you only actually use your BT-848 card but one in 10 times you boot. Everyone suffers. (b) A hypothetical OS has the ability to defragment physical memory. It does this by taking the physical pages that haven't actually been allocated to physical memory descriptors given to peripheral memory bus devices, including main memory in the kernel, locking out use of the physical page, and moving the virtual mapping to point to a different physical page. For pages for in use data (including kernel data), it copies the data from the old page to the new page; for not-in-use I/O descriptors, it just points to the new page. Virtual memory is the same, but actual physical memory has been defragmented. A large chunk of physically contiguous memory is now available, and can be allocated and deallocated at need. No one suffers. This is an OS function because the mapping from virtual to physical is an OS function, and because the OS arbitrates who gets to run when, and (hopefully) intermediates the visibility of data between I/O descriptors in the OS, and physical memory buffer descriptors on the device. (2) You have a device with an insufficient number of address lines For these devices, you want to preferrentially allocate the physical memory so that it's reachable by the device. The classic example here from the IBM PC world is plugging 16 bit AT bus cards into a 32 bit system, and wanting them to work. For the card to reach the memory it's being asked to DMA to/from, that memory has to be in the low memory (how low depends on how few address lines the card actually has). The solution in this case is what's called a "bounce buffer": if the memory is in range,it's accessed directly; if not, the communication is "bounced" through a buffer in low memory which *is* reachable by the device. This is an OS function because there is a very limited range of memory in which you can place a bounce buffer and have it reachable by the device, but you must share this scarce resource with other devices, and the OS must be able to decide whether or not it needs to use the buffer. (3) You have a device with enough address lines This is a variant of case 2: instead of allocating bounce buffers, you preferentially place allocations in high memory so that when/if you have another device of type #2 competing for resources, you can stay out of its limited view. This is an OS function for the same reason #2 is an OS function. (4) The OS likes to be kept informed of information for its own reasons so it can play tricks behind your back The tricks themselves don't matter, what matters is that you enable performance and power management winds by following the rules; if you don't follow the rules, and try to avoid the OS interfaces, you also avoid the OS signaling mechanisms that are used to implement these optimization. Unfortunately for you, this is like declaring a variable that is modified out of scope, and not marking it volatile: failure to notify the OS of the nature of your access means the OS gets to do any optimization it wants. For a volatile variable, that may mean not exiting the work loop when the signal handler fires. For a device driver, it generally means a panic in the driver. -- Terry On Aug 6, 2010, at 7:02 PM, shailesh jain wrote: > Thank y'all! Let's see how things work out. ;) > > On Fri, Aug 6, 2010 at 12:36 PM, Terry Lambert <tlambert(a)apple.com> wrote: >> What Shantonu and Mike said. >> >> -- Terry >> >> On Aug 6, 2010, at 1:47 AM, shailesh jain wrote: >>> terry ? >>> >>> On Thu, Aug 5, 2010 at 11:10 AM, shailesh jain >>> <coolworldofshail(a)gmail.com> wrote: >>>> Hello again! >>>> I have a kernel extension (which is not an IOKit driver) that uses >>>> OSMalloc_ KPI to allocate buffer. I pass in OSMT_DEFAULT so that >>>> buffers that it returns are wired to memory. I have a use case where >>>> in I would like >>>> to get physical address of the first byte of the buffer. I understand >>>> that buffer will not be contiguous in Physical memory and I am fine >>>> with that. Do we have such an interface --- >>>> >>>> something like: physAddr = virt_to_phys(buffer); // Gives physical >>>> address of first byte of the buffer _______________________________________________ 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: Getting Physical address of a buffer
by Michael Smith 07 Aug '10

07 Aug '10

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: Getting Physical address of a buffer
by shailesh jain 07 Aug '10

07 Aug '10

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:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TJ0nA91WCACv4HxdN459NQ05aCDO6W7mGu3cMlqRTBI=; b=S42NWpia3SrxraCS7e6M2KZntKKNOJehBkLCYu9ejPvJSpNVoaZDfTVKtXzhAYkjiL UShV1hfjpWsOvW8PxHXxYTazuQl5Bbx66oDc6BAz4wwSXJxSSk/i4qk0cYTieyMvDzUm /QZsma3IgoHeGki97A+BPu5HA/nNvS8r4wYl4= 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:content-transfer-encoding; b=W35+fHGPtkQDVfzy+IF3Cq5tHIlQKjchnW/3ddvg3lyiEhjdXnnPxjXp0mbEV+WMtD UNaW7A0K5aQkBsVW4ZaTUklP5uMzUqkQdiayO7SuD1CgoWs8s7oMn/2FAVcgdPGBnNbR FrFNZgloBGMKzI/NsHlQJYoOpzVKEZhT+Ql6Y= Thank y'all! Let's see how things work out. ;) On Fri, Aug 6, 2010 at 12:36 PM, Terry Lambert <tlambert(a)apple.com> wrote: > What Shantonu and Mike said. > > -- Terry > > On Aug 6, 2010, at 1:47 AM, shailesh jain wrote: >> terry ? >> >> On Thu, Aug 5, 2010 at 11:10 AM, shailesh jain >> <coolworldofshail(a)gmail.com> wrote: >>> Hello again! >>> I have a kernel extension (which is not an IOKit driver) that uses >>> OSMalloc_ KPI to allocate buffer. I pass in OSMT_DEFAULT so that >>> buffers that it returns are wired to memory. I have a use case where >>> in I would like >>> to get physical address of the first byte of the buffer. I understand >>> that buffer will not be contiguous in Physical memory and I am fine >>> with that. Do we have such an interface --- >>> >>> something like: physAddr = virt_to_phys(buffer); // Gives physical >>> address of first byte of the buffer > > -- Shailesh Jain _______________________________________________ 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: Getting Physical address of a buffer
by Terry Lambert 06 Aug '10

06 Aug '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com What Shantonu and Mike said. -- Terry On Aug 6, 2010, at 1:47 AM, shailesh jain wrote: > terry ? > > On Thu, Aug 5, 2010 at 11:10 AM, shailesh jain > <coolworldofshail(a)gmail.com> wrote: >> Hello again! >> I have a kernel extension (which is not an IOKit driver) that uses >> OSMalloc_ KPI to allocate buffer. I pass in OSMT_DEFAULT so that >> buffers that it returns are wired to memory. I have a use case where >> in I would like >> to get physical address of the first byte of the buffer. I understand >> that buffer will not be contiguous in Physical memory and I am fine >> with that. Do we have such an interface --- >> >> something like: physAddr = virt_to_phys(buffer); // Gives physical >> address of first byte of the buffer _______________________________________________ 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: Getting Physical address of a buffer
by shailesh jain 06 Aug '10

06 Aug '10

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:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=C08ovIZKCrTz8WEAYYqA47kitXoX1LOFEWpMUgLbiTc=; b=RreZrZ1u0FwFkUysuZLO3u/0VGMSY1KlQ25ySYI40m9123UZH+kGO+PgBhshd0dLow lLH7m4sE7JW9UB+PEZJkacug9woocCDBKq+n8Z2qteORirbNBlkmM/WBlygYh5ROOyiW p+MNRhSnQohE3FhIRFTKyA2545BQXa0z+mrmY= 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:content-transfer-encoding; b=UpESLzP3wkscwNPVawqhuLiugZzCjDIXXxyo0hZ+yiCMfICVHRdqW6uLVmL/2QHHNC JuiwH4BAoyUmOgUxqcBp4S5eSu7VwhRQfLKCfBHtvD9lwIarFDKtJj53XjvdBzHBullO 1Wsrlx1cVu/pe7/SEJA3lfKlnfF7lWhhn8Kv8= @Shantonu - I was under the impression that IO* KPIs should only be used by IOKit driver ? @Mike - Virtualization. If you care to involve hypervisor in your memory tricks then virtual address of the guest buffer is useless. You want physical address. @Others - I will check KPIs that you guys mention. Seems like most device drivers that care about DMA would probably be an IOKit driver else what I am asking for seems like very basic requirement. Shailesh Jain On Fri, Aug 6, 2010 at 9:18 AM, Michael Smith <drivers(a)mu.org> wrote: > > Why would you like to get the physical address of this buffer? What do you > think it will tell you? > = Mike > On Aug 5, 2010, at 11:10 AM, shailesh jain wrote: > > Hello again! > I have a kernel extension (which is not an IOKit driver) that uses > OSMalloc_ KPI to allocate buffer. I pass in OSMT_DEFAULT so that > buffers that it returns are wired to memory. I have a use case where > in I would like > to get physical address of the first byte of the buffer. I understand > that buffer will not be contiguous in Physical memory and I am fine > with that. Do we have such an interface --- > > something like: physAddr = virt_to_phys(buffer); // Gives physical > address of first byte of the buffer > > > -- > Shailesh Jain > _______________________________________________ > 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/drivers%40mu.org > > This email sent to drivers(a)mu.org > > -- > The lyf so short, the craft so long to lerne -- Chaucer > > > > > -- Shailesh Jain _______________________________________________ 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: IOBlockStorageDriver::synchronizeCache
by Michael Smith 06 Aug '10

06 Aug '10

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: Getting Physical address of a buffer
by Michael Smith 06 Aug '10

06 Aug '10

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