site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com <http://lkcd.sourceforge.net/doc/index.html> Sam _______________________________________________ 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... 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? This email sent to site_archiver@lists.apple.com