Jim Magee writes:
That's just the way BSD headers do things. To change it would break
BSD [in-kernel] compatibility. But having BSD [in-kernel]
compatibility also implies something else. As you will see, the
definition of struct ipovly [the type for the ti_i field] is marked
__APPLE_API_PRIVATE. That's you indicator that you have to be prepared
to have your software track the OS on a release-for-release basis.
I see your point, but ipovly is not a good example. Unless you're planning to reimpliment IP so that you can't talk to anybody else, I doubt that ipovly will be changing much ;)
If that's not your cup of tea (and it's certainly not the typical
business model of any long-time Mac developer), we are in the process
of creating a set of more sustainable APIs for such kernel extensions.
But as good as we are at guessing your needs, we aren't psychic. You
[all] need to let us know what services you need sustainable interfaces
for. Well do our best to include those [or comparable equivalents].
I could make all uses APPLE_API_PRIVATE headers go away in my driver (OS-Bypass cluster interconnect -- http://www.myri.com/scs/macosx.html) if somebody would just fix the VM system so that it wouldn't block a user process indefinatly if said process attempts to free memory locked via IOMemoryDescriptor's prepare function. But I couldn't seem to get anybody interested in changing this behaviour in the past... Regards, 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.