Re: Obtaining non-exported symbol from kernel on runtime (without the debug symbols)
Re: Obtaining non-exported symbol from kernel on runtime (without the debug symbols)
- Subject: Re: Obtaining non-exported symbol from kernel on runtime (without the debug symbols)
- From: Mike Zuhl <email@hidden>
- Date: Mon, 15 Dec 2008 02:13:50 -0800
On Dec 15, 2008, at 12:26 AM, John D. wrote:
Honestly, why don't you start bringing up some technical statements
here? You keep resorting to either avoiding answering altogether, or
replying with meaningless comments about why people should blindly
take your statements and superior all-seeing knowledge for granted.
Think higher level, John. A kernel that is a stable environment for
all flavors of KEXTs over many versions is a very valuable thing. In
order to have stability and still have room to innovate and improve
you must have a defined interface between KEXTs and the rest of the
kernel. This API is in effect a promise from the kernel developers to
the KEXT developers that certain facilities will always be available.
Defining this interface is a balancing act. The interface must be
rich enough to create efficient KEXTs, yet be limited enough to allow
the kernel developers to make improvements. Think about Snow Leopard:
I don't know the details of Grand Central but I do know that
converting a BSD kernel to use "scores of cores" requires lots of
changes in lots of places. The kernel developers can do this while
retaining their "promise" to the KEXT developers because the kernel
developers have reserved "design room" on their side of the API.
Defining a perfect API requires perfect knowledge of the future, which
is not often available. If the designers allow too much to be
available in the API, it can make future functions or performance
improvement impossible. If too little is a available in the API, then
KEXT developers are hampered. After an API is published it is far
easier to allow additional functionality in the API than to remove
functionality (which costs real money to KEXT developers). Because of
this, API designers tend to err on the side of less functionality and
provide a mechanism like DTS to allow KEXT developers to make a case
for more.
So the issue isn't FreeBSD, NetBSD, or Linux. The issue isn't kauth
or the syscall table. The issue is a _software engineering_ issue of
defining interfaces so both sides of the interface can both be stable
and make progress. It is literally a case where "less is more." By
making a stable interface everyone really can get more done.
John, you are complaining either about the whole concept of
interfaces, or how the current OS X interface is defined. If it's the
former, you need to learn more about software engineering before
complaining. If it's the latter, then file a bug to ask that a
function be added to the API.
--Mike Zuhl
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden