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: Mon, 25 Jul 2005 17:33:46 -0700
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
On Jul 25, 2005, at 4:51 PM, Sam Vaughan wrote:
Hi Josh,
Thanks for the speedy reply. I'm only interested in sending/
receiving to/from kernel memory here so that's not a concern right
now.
Don't you agree however that in moving from soreceive() to
sock_receive(), the interface has dropped in usefulness? The idea
of allocating yet another uio, walking the iovecs in my own one and
adding new iovecs with the appropriate addresses and lengths to the
new one makes me shudder. That'd be three uios allocated, prepared
and freed just to do one I/O operation - one in our platform-common
code, one in the 10.4 wrapper around sock_receive(), and another in
sock_receive_internal().
One more entry point that takes a uio and passes it straight to
soreceive would be a real bonus, for elegance, performance AND
sanity ;o)
Sam
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