Re: Mac OS X 10.4 (Tiger) compilation errors ( GCC v3.3 ) with X Code 2.0 tool
site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Karunakar Reddy G writes:
But it is defined on Tiger as follows *int* *copyin*(*const* user_addr_t *uaddr*, *void* **kaddr*, *size**_**t* * len*); *int* *copyout*(*const* *void* **kaddr*, user_addr_t *udaddr*, *size**_**t* *len*); Now, My problem is I don't have option to copy void * to void *, which is very important in my driver, why they removed such a beautiful option? Is there any other new functions are available? Is it possible to use same functions, then can any one have example to use of them?
The move to user_addr_t was done so that Apple could continue to have a 32-bit kernel and still deal with 64-bit applications. If you're talking to a 64-bit application, a kernel's void* is only 32-bits, so any address above 4GB would not be accessible to copyin or copyout. I had to go through our code, identify anything which is used to store a user address, and convert it to use a user_addr_t. I expect you are about to emark on a similar fun experience. <rant> This was an enormous pain for me to deal with, since on every other operating system we support (even the real 64-bit ones) a kernel void* is wide enough to hold any user pointer. It would have been much easier for us to use a Solaris (or AIX) like driver model, where you supply a 32- and 64- bit driver, and the appropriate one gets loaded depending on the booted kernel. This would have been especially easy with fat binaries. </rant> OTOH, you can avoid the whole mess if you're willing to limit yourself to dealing only with 32-bit processes. Then you can just cast things down to a void*. Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com
participants (1)
-
Andrew Gallatin