site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Hi Sam, Thanks, -josh On Jul 25, 2005, at 4:51 PM, Sam Vaughan wrote: Hi Josh, _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com 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 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 smime.p7s