site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Jul 25, 2005, at 6:08 PM, Sam Vaughan wrote: <snip> -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 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) 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. 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. Radar is the right place to make requests for missing functionality or report a bug with the current implementation. 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. smime.p7s