Apple's position on NKEs (was "Re: Basic Question: Internet Content Filter")
Apple's position on NKEs (was "Re: Basic Question: Internet Content Filter")
- Subject: Apple's position on NKEs (was "Re: Basic Question: Internet Content Filter")
- From: Peter Sichel <email@hidden>
- Date: Wed, 14 Jan 2004 02:14:21 -0500
On Jan 13, 2004, at 8:44 PM, Joshua Graessley wrote:
That would be surprising since Apple and several 3rd party products
make heavy use of them. NKEs are a central feature of the Mac OS X
network implementation.
The NKE APIs are not officially supported. If you write an NKE, there
is a very good chance that your kext may break in the future release
(we don't guarantee binary compatibility). I think you might also have
trouble getting support from DTS. As we mentioned at WWDC last year,
we're working on some "KPIs (Kernel Programming Interfaces)" that will
enable us to guarantee binary compatibility in the future and give you
a better API to work with.
"Not officially supported" is a somewhat troubling phrase that I'd
like to expand on even though I can't speak for Apple. It may help
to understand some of the history behind this.
The whole NKE mechanism was developed by Apple in response to developer
requirements based on moving from STREAMS (a plug-in architecture for
networking) to BSD (an open source compatible architecture).
In brief, Apple is caught in a difficult situation. They need the
ability
to update the Kernel (for 64-bits and multi-threading), but once a KEXT
is loaded, they have no control over what kernel structures it accesses.
It's all one global address space.
Their solution is to not guarantee binary compatibility of the
kernel between major releases (once a year). That is, NKEs may need to
be recompiled depending on what kernel data structures they access.
Since NKEs are the only game in town for solving a certain class of
problems, it is fully understood that a small number of developers
will use and depend on them. Apple's position is to make developers
aware of the risks involved and discourage anyone who isn't required
to use these APIs.
In our case, we are accessing some fairly mature data structures in the
BSD stack along with some DLIL (Data Link Interface Layer) functions
designed for this purpose. It seems reasonable that Apple won't take
these away before offering a viable alternative or change them
recklessly
since they are used internally as well. We did need to rebuild our
NKE to work on 10.2 versus 10.1. Mac OS X 10.3 and 10.2 are able to use
the same NKE.
The proposal to not provide binary compatibility between releases was
controversial within Apple. Developing stable KPIs (Kernel Programming
Interfaces) was part of the compromise. While politically necessary,
it's unclear how soon they will appear. It's a rather difficult problem
because the requirements are not well specified. Which kernel
structures
need to be exposed behind stable interfaces... all of them?
NKEs are the solution Apple promised 3rd party developers. They've just
had to backtrack a little to get around the open source versus binary
compatibility knot.
- Peter Sichel
Sustainable Softworks
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.