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: Amanda Walker <email@hidden>
- Date: Mon, 15 Dec 2008 09:26:04 -0500
On Dec 15, 2008, at 3:26 AM, John D. wrote:
You've already used the whole FreeBSD kernel code base,
Stop. You keep repeating this, and it is not true.
Honestly, why don't you start bringing up some technical statements
here?
Everyone who has responded to you has been giving you technical
answers. You just aren't listening to them, since you don't like
those answers, and keep raising political objections to them.
I care about why kauth is severely limited,
feature lacking and almost useless in XNU.
It's not. Quite a number of successful products use it quite nicely,
thank you.
I care about why most
process, BSD thread or locking API has been crippled in XNU.
Because XNU is not FreeBSD or NetBSD, despite sharing some DNA.
If you plan on breaking ABI on every minor update, you might as well
stop releasing source.
No. How about "If you plan on breaking compatibility with FreeBSD or
NetBSD, you might as well call your OS something else." Which is, in
fact, exactly what happened. *Years* ago.
But then stop marketing XNU or
Mac OS X as an open source or 'openly available and developer
friendly' platform.
"Open source and developer friendly" has *nothing* to do with
maintaining compatibility with the internals of other operating systems.
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.
Sure it does. It just means you'll have to find a different way to
write your driver than you expected to. Having developed both FreeBSD
and IOKit drivers, I can say that IOKit is much more "developer
friendly" in most ways than the FreeBSD or NetBSD kernel driver
infrastructure.
In the end only Apple is able
to provide closed source or binary-only drivers,
Not so. I've personally shipped several closed source drivers (and
made plenty of money from them). And thanks to well defined KPIs and
binary compatibility, I've been able to ship single builds that work
across multiple major revisions of the kernel.
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.
If you think this is what has been happening on this thread, you are
wrong. You are throwing a temper tantrum because Darwin does not
conform to your expectations from FreeBSD. You aren't the first
person to do this, but it's generally not the best way to do
engineering.
--Amanda
_______________________________________________
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