site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=THfH0Tz2ECjCIY9wGU0mSilhnLRijQXvRgfvr02TbMg=; b=RG9p4DD39E7dmf5wyU24aCRqIE35atfeOQqaeAgBNMiB19Lffy26WYUFgdugjwlL6W iN8TQgfnt9FMYoDEXP/ZGYQtmG2r/gqfMnZjphHrrA7/qC8DO7LehVkQ+p56ap1jB3CE yS+80r9B9AJsIdd77BGhIhoc2NWPEq+9JC7h4= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ZmD13/GSOidA7rb8T4kVP7NcxpFSkoKevcYMA75WvlQzJt3gjIYvNy1y20YpKmv7AM pSdRV+zHuVU66HsNVbjgzdGcJF+gOqkTP+LgW16E6593o6n5SmhG6mq8wNpQih9a9i1j SKI2UGufH9aB0oU2gZy3xNlYDqV1lpkGchXMM= On Mon, Dec 15, 2008 at 8:56 AM, Terry Lambert <tlambert@apple.com> wrote:
On Dec 14, 2008, at 10:16 PM, "John D." <johndenkar@gmail.com> wrote:
On Mon, Dec 15, 2008 at 6:50 AM, Terry Lambert <tlambert@apple.com> wrote:
On Dec 14, 2008, at 9:02 PM, "John D." <johndenkar@gmail.com> wrote:
Excuse me, but monkey business is taking FreeBSD and Mach, creating a hybrid kernel, and crippling the API in a manner that doesn't let third-party developers exercise the best of both systems. Is that common sense?
John, step down.
I am the senior engineer on the Kernel team for BSD, Mike is more senior than me, and Dean Manages the IOKit team.
"No" means "No".
I'm not questioning your knowledge here nor that of anyone else. I've got no time for it and no interest. Really. I came here asking why the BSD interfaces have been crippled to a certain extent, and that's it. If you don't want to provide a consistent answer it's fine, just don't enter a red herring argument about what makes your actual statements more reasonable than mine, when you are not providing technical facts supporting them. I could care less about your alleged pedigree. If one's professional position and its required knowledge matches his current skillset and reasoning is, again, moot.
We might as well move on the question I sent about mbuf structures and NKE ipfilters. Those interfaces are examples of good work you've done there, so congratulations for that one. On other hand. I still think kauth is severely limited (crippled) as it is implemented right now. Check the current NetBSD code which is what you ported to XNU originally and adapt the new changes to XNU (from -CURRENT).
We originated kauth. It is not a port from NetBSD. Thanks for playing, though.
If you originated it, then, why do you let NetBSD improve it beyond its current status in XNU itself? It's not like the BSD licensing stops you from taking their improvements. You've already used the whole FreeBSD kernel code base, porting some cleanroom implementation of your own kauth subsystem and improving it, can't hurt. Right? I guess you don't read NetBSD development lists regularly: http://archives.neohapsis.com/archives/netbsd/2007-q2/0023.html It's almost 2009 here. That thread is old enough to have gone unnoticed. 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. Do you think I truly care on who originated kauth or who decided to cripple ABI in XNU kernel updates shipped customers after every major release or minor revision? I care about why kauth is severely limited, feature lacking and almost useless in XNU. I care about why most process, BSD thread or locking API has been crippled in XNU. If you plan on breaking ABI on every minor update, you might as well stop releasing source. Since you bring up the argument of 'customer support'... well, you suggest independent vendors shall ship custom builds of the XNU kernel to their customers and replace the official one shipping with OS X altogether? What kind of responsible development or life cycle is one which causes major ABI changes across third-level updates or minor releases? Even Linux 2.6 development people have got that right to a certain extent after a long time of finding themselves with severely broken drivers in the development tree. You want to break or cripple BSD kernel standard API? OK. You want to provide limited, restrictive interfaces branding them as KPI (when you are merely doing arbitrary changes to exported symbols and removing the availability of most of them)? That's fine too. You want to avoid answering questions from developers about why you've taken this decision single handed? That's fine! But then stop marketing XNU or Mac OS X as an open source or 'openly available and developer friendly' platform. If your developers can't write drivers because you've intentionally crippled your ABI/API, your platform does not qualify as open or developer friendly. In the end only Apple is able to provide closed source or binary-only drivers, not to mention the detrimental effect on potential third-party development of features that your user base might consider far more useful and necessary than what you might think in first place. So yeah, let's all drink the kool-aid and spice it up with some LSD and candy. No wonder some run out of arguments when they start repeating themselves over and over like a broken record. -- John Denkar _______________________________________________ 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... This email sent to site_archiver@lists.apple.com