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: Sam Vaughan <email@hidden>
- Date: Wed, 27 Jul 2005 09:46:35 +1000
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.
Really? I've been half expecting Software Update to modify my
Kernel.framework Headers directory during 10.4.x updates.
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.
Agreed. I'd still like to push for the return of uio interfaces per
my Radar report though, especially considering the simplicity of the
implementation on the KPI side: if have uio, pass it down, else
create one using the msghdr.
Implementing the code to generate a new set of iovecs to specify the
I/O region of a uio was non-trivial once all the edge cases and
performance issues were taken into account. Small iovec count
operations are handled using iovecs on the caller's stack, operations
that start and end on iovec boundaries in the original uio use the
original uio's iovecs, and if all else fails, new iovecs are
allocated. It's all encapsulated in a function to be called from
sending or receiving code, and the debug-mode tracing and
verification code at the end of it is nearly as big as the function
itself.
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.
I fully understand this, hence the smiley for facetiousness :o) On
the other hand, our customers aren't Joe Users, their system
administrators govern when their machines are upgraded and we could
mandate a particular OS minor point release if we had to. It's not
that I don't want to use the KPI, it's just that there are so many
areas where things are missing. Sockets are just this week. I'm
also trying to deal with setting arbitrary dev_t values in buf_t
objects, accessing the try variants and determining the current state
of read-write locks, getting a device switch table entry from a major
number, interrupting threads sleeping on sockets, timeout/untimeout,
thread_abort_safely, ... and that's just the platform support code.
Who knows what vfs, vnode lifetime, lookup, mmap and UBC issues still
await!
Ah it's all fun and I don't want this to sound like a rant, I'm just
trying to put this issue in perspective. I'm VERY pleased to have
funnels out of the picture, to have so much of the lookup and name
caching work handled for us, the prospect of good lock statistics à
la Solaris, and maybe even practical kernel dumps. All we need now
is a proper run-time kernel debugger. Hmmm... mcrash anyone?
<http://lkcd.sourceforge.net/doc/index.html>
Sam _______________________________________________
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