site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Sam On 26/07/2005, at 10:33 AM, Josh Graessley wrote: Hi Sam, Thanks, -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... 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) 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. This email sent to site_archiver@lists.apple.com