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: Tue, 26 Jul 2005 11:08:12 +1000
You're right, Josh, I don't need to allocate another uio, but I do
need to allocate more memory for iovecs, despite already having some
perfectly good ones of my own. I suppose the crux of it is that the
msghdr interface is half-way to the usefulness of uio. If it only
allowed you to specify one address and length then I probably would
have just coded to it and forgotten about it straight away.
I understand your position though. Evidently the majority of people
using your KPI are writing to it from scratch rather than building a
common code base that runs in the kernels of several OSes. It'd be
hard to imagine anyone not using uio structures if they were also
targetting other UNIX platforms.
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)
Sam
On 26/07/2005, at 10:33 AM, Josh Graessley wrote:
Hi Sam,
You don't need to allocate another uio. You just need to allocate
some iovecs. The uio is handy for you because you happened to have
a uio available for other reasons. When we looked at what most
kexts were doing, we found that 90+% of them had to allocate and
fill out a uio just to send some data. We wanted to make it easier
by dealing with the uio so the kext developer didn't have to worry
about that. Your request is the first we have received for a uio
variant. There are probably more developers frustrated that they
have to fill out an iovec array to describe their data instead of
passing a pointer and length.
We will not be able to add a uio variant in a software update
(10.4.x). This means you would need to wait for the next major
release at the earliest for such a function. Since you will have to
work around this problem to support 10.4.x, I'm not sure it makes a
lot of sense to add this function. If we hear more requests for a
uio variant of the send and receive functions, I will look in to
getting those in.
Thanks,
-josh
_______________________________________________
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