Shawn Erickson writes:

Why don't you have your API provide memory allocation and deallocation

functions that do the needed driver interaction for them? Clients of you

API would be required to use your methods and all would be well.

If they don't want to use your methods that is ok but then they must

deal with the issue themselves.

All of that is done as you say. They can choose between letting us allocate memory for them, or they can choose to "register" (wire) memory they've allocated themselves. For our most popular middleware (MPI) we have a shim layer that overrides malloc and free in the library they link with & makes sure to "deregister" (unwire) memory before calling the real free to help prevent erorrs. (it also provides a registration cache for platforms where pinning memory is expensive) But there is a huge base of existing code that our users port to our system; using the api correctly is sometimes more than they can handle. Even though its rare, when they shoot themselves in the foot our QA people think a crashed application with a bus error is acceptable notification, but an uninterruptible hang is not. Drew _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.