Re: 32/64-bit App with User Client
Re: 32/64-bit App with User Client
- Subject: Re: 32/64-bit App with User Client
- From: "Duane Murphy" <email@hidden>
- Date: Thu, 26 Feb 2009 10:16:09 -0800
Updating my own question. I'm teasing through this...
>For example, the first parameter to withAddressRange() is of type
>vm_address_t which is an unsigned int (4 bytes). How does that work when
>the address comes from a 64-bit application where the address is 8 bytes?
This statement was incorrect. The first parameter to withAddressRange()
is a mach_vm_address_t which is uint64_t, in both SDKs. That seems helpful.
--- At Thu, 26 Feb 2009 09:51:33 -0800, Duane Murphy wrote:
>We are moving our applications to compile in 64-bit mode. However, we
>also have kexts that obviously are 32-bit.
>
>We need to pass large'ish (>4K) blocks between the app and the kext.
>
>Presently the data structures passed from the app to the kernel include
>pointers. Those pointers are then mapped using
>IOMemoryDescriptor::withAddressRange().
>
>So the obvious problem is how can we create data structures that are
>32/64 bit neutral that can still pass pointer references to a 32-bit
>kernel? That is, on some platforms the app will be 32-bit while others
>64-bit, while the kernel is 32-bit.
>
>For example, the first parameter to withAddressRange() is of type
>vm_address_t which is an unsigned int (4 bytes). How does that work when
>the address comes from a 64-bit application where the address is 8 bytes?
>I have been reading the 64-bit porting guide, but I have not found how
>to fix this problem.
>
>Any references or suggestions are most welcome. (I haven't been able to
>find anything in the list archives yet.)
>
> ...Duane
>
> _______________________________________________
>Do not post admin requests to the list. They will be ignored.
>Darwin-dev mailing list (email@hidden)
>Help/Unsubscribe/Update your Subscription:
>
>This email sent to email@hidden
>
...Duane
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden