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: "John D." <email@hidden>
- Date: Mon, 15 Dec 2008 09:26:32 +0100
On Mon, Dec 15, 2008 at 8:56 AM, Terry Lambert <email@hidden> wrote:
> On Dec 14, 2008, at 10:16 PM, "John D." <email@hidden> wrote:
>>
>> On Mon, Dec 15, 2008 at 6:50 AM, Terry Lambert <email@hidden> wrote:
>>>
>>> On Dec 14, 2008, at 9:02 PM, "John D." <email@hidden> 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden