Re: sock_receive_internal() and its (ab)use of uio
Re: sock_receive_internal() and its (ab)use of uio
- Subject: Re: sock_receive_internal() and its (ab)use of uio
- From: Josh Graessley <email@hidden>
- Date: Tue, 26 Jul 2005 08:49:18 -0700
On Jul 25, 2005, at 6:08 PM, Sam Vaughan wrote:
<snip>
Out of curiosity, I thought that one of the motivators for the KPI
was to give you the ability to make more changes in point releases
of the OS. The KPI should permit you to change the contents of
struct socket, let alone to just add another KPI entry point in
kpi_socket.[ch].
Or, to put it another way, if you guys aren't going to make big
changes to the KPI in minor releases, what's stopping us from
linking to mach_kernel and overwriting our Info.plist's
com.apple.kernel entry with the output of `uname -r` before loading
our kext? ;o)
We don't have a good way to deliver new headers with software
updates. No header means no prototype or documentation for the new
function.
The motivation of the KPI is to give us the freedom to fix bugs, add
features, and improve performance without breaking third party kexts.
The whole point of the KPI is that we can make big changes internally
without making any change to the KPI. We don't want to go crazy and
have a dozen ways to do everything. The more functions we supply, the
more we have to maintain and the more limits we have on the changes
we can make in the future. We have to balance requests for everything
every developer ever asks for with our need to have a clear,
coherent, lightweight, and easily maintainable interface for developers.
Radar is the right place to make requests for missing functionality
or report a bug with the current implementation.
There are a variety of reasons not to use uname -r as you suggest
above. I would hope the thing that stops most developers is their
interest in shipping a robust, quality product to their customers.
When you are writing kernel code, you need to be careful. If you link
directly against the kernel, you are probably doing it because you're
doing something skanky. Some day, when some assumption you are making
breaks, your customer will suffer. All the finger pointing in the
world won't bring back the lost productivity and data. If we don't
work together, the end user suffers.
-josh
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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