site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com 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. --Mike Zuhl _______________________________________________ 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... 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. This email sent to site_archiver@lists.apple.com