Re: Leopard Sources?
Re: Leopard Sources?
- Subject: Re: Leopard Sources?
- From: Michael Tuexen <email@hidden>
- Date: Mon, 5 Nov 2007 15:57:39 +0100
Hi Quinn,
thank you very much for your answer. It helps to understand why Apple is
acting like it is.
More comments in-line.
Best regards
Michael
On Oct 30, 2007, at 11:29 AM, Quinn wrote:
At 21:00 -0600 29/10/07, William Kucharski wrote:
It's not divulging trade secrets to give general areas which are/
remain closed source.
OK, I'll bite (-:
I know of three main areas:
o A significant chunk of what gets removed is comments. They
might, for example:
- contain information related to upcoming hardware
- explain workarounds for bugs in third party code, where Apple
doesn't want to be seen as publicly criticising a third party
- explain workarounds for Apple code, where Apple doesn't want
to be seen as being critical of itself
o Some stuff is code that we received under non-disclosure from
another party, or code based on information that we received under
non-disclosure from another party.
o Some stuff is removed because it relates to upcoming Apple
products. For an extreme example, consider that, prior to the
iPhone announcement, it would have been extremely foolish to reveal
full support for the ARM platform.
Having said that, Apple works hard to ensure that:
a) Darwin can build and run as a standalone OS.
b) You can slide a "mach_kernel" built from open source underneath
Mac OS X, and things still work.
So, while the Darwin kernel source is slightly different from
Apple's internal source, you'd be hard pressed to find a situation
where that makes any difference in practice. If you discover such
a situation, please let us know by filing a bug.
At 18:30 -0600 29/10/07, William Kucharski wrote:
The irony is that in PPC days the kernel was fully open sourced
and it was only various libraries, such as the ones having to deal
with DVDs, that were closed source.
This is /not/ true. The situation I've described above has
existing since the first Darwin release.
* * *
Obviously it is possible to improve things in this space. For
example, we could have a group of engineers dedicated to keeping
the open source and the internal source in close sync. Doing this,
however, would require Apple to rebalance its priorities: to
increase our commitment to open source requires a corresponding
decrease in the cool features that we can ship to customers (and
developers).
Decisions like that are made well above the pay grade of the folks
that read this mailing list. To be blunt, complaining in this
mailing list won't help. The Apple folks who read the list are
just a bunch of kernel engineers. Regardless of whether we agree
or disagree with you, it's not our decision to make.
What you should do is corner an Apple marketing person [1] and
explain to them the consequences of the current priorities. When
you do that, avoid emotional appeals; rather, explain how the
current policy negatively impacts Apple (either in dollar terms, or
in terms of lost opportunity).
* * *
With regards SCTP, we already have plenty of bugs covering this.
The two lead bugs are:
<rdar://problem/3893228> Protocol plug-in KPI
<rdar://problem/4605154> Requirement for SCTP implementation on Kernel
The first covers the requirement for a general protocol plug-in
KPI, and the second covers the specific requirement for an SCTP
implementation.
Again, fixing this is a matter of priorities. In the three years
since I filed <rdar://problem/3893228> I've encountered /two/ third
party developers that need a protocol plug-in KPI:
A. The first was commercial developer with a significant source
base that was dead in the water on 10.4.x without this KPI. At the
time this way a major kerfuffle. After a prolonged discussion,
these folks eventually decided to change their in-kernel protocol
code so that it was no longer an actual protocol (IIRC they hosted
it on top of a UNIX domain socket, so the majority of their code
could continue to use sockets for read, write, select and so on).
They're now fully hosted on KPIs, and their code is more-or-less
binary compatible with Leopard.
B. The second is SCTP, as built by Michael and used by Andreas.
This project continues to use the kernel's protocol plug-in
mechanism, even though this isn't an official KPI. As such, it
doesn't get the benefits that KPIs provide. That it, it is
sometimes broken by dot releases of the OS, and it pretty much
always broken by a major release. And it can't be fixed without
Darwin source.
* * *
Michael, Andreas, you have a decision to make. You can continue
down your current path, with the negative consequences that I've
described above. It's possible that Apple will eventually
introduce a protocol plug-in KPI, but I can't say if or when that
will happen. However, given that this is /not/ in 10.5, it seems
likely that you'll be suffering this pain for years to come.
Alternatively, you can find some other way to implement the
functionality that you need. Perhaps you can move your protocol
into user space? Or perhaps rehost your in-kernel code on top of
UNIX domain sockets? I realise that this will be technically
challenging. Ultimately, it's a question of balancing the pain of
this change with the pain that you suffer by not being hosted on
supported KPIs.
I already developed an SCTP implementation in userland and this is
not what we want. SCTP has a standard socket API
like TCP and UDP hat. Solaris, Linux and FreeBSD support it. So I
want to have not only an SCTP implementation
available on Mac OS X but also being able to use it via the standard
socket API defined in
That is why we have the pain... If the possibility of the NKE is not
possible anymore in a future version
of Mac OS X, I would integrate it directly in the kernel (like TCP
and UDP) and would use a modified mach_kernel.
However, it is much easier to use a NKE, because you can recompile/
reload the NKE without rebooting. This
helps during debugging.
I'm sorry to be so blunt about this. I'm sorry that we don't have
a better story for you. I wish that we had infinite resources and
could accommodate all of the needs of all of our developers. Alas,
that just isn't the case.
Share and Enjoy
--
Quinn "The Eskimo!" <http://www.apple.com/
developer/>
Apple Developer Relations, Developer Technical Support, Core OS/
Hardware
[1] Actually, Apple Developer Relations, and hence DTS, is part of
marketing, but I pride myself is being the "most technical person
in marketing" (-:
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40lurchi.franken.de
This email sent to email@hidden
_______________________________________________
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