site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Peter, Because: -- Terry _______________________________________________ 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... On Aug 18, 2005, at 2:18 AM, Stephane Sudre wrote: On 17 août 05, at 22:16, Vincent Lubet wrote: In fact, starting with Mac OS X 10.4.2, a call to getsockopt() on a kernel control socket will copy the user data into the kernel buffer. This should provide for the read/write behavior you're looking for. I'm not sure to fully understand the logic in changing the getsockopt behavior instead of just introducing a new API. I mean: what is the purpose of the KPIs if you still need to hack the APIs? - this introduces incompatibilities with previous release of the OS. It's working on 10.4.2 but not on 10.4. So adding a new API would have just been fine. If we add a new API to the KPIs in 10.4.2 and it's not in 10.4.0 or 10.4.1, then any KEXT using the new API will not run on 10.4.0 or 10.4.1 because of link errors when it is attempted to be loaded. The entire intent of the KPIs is to ensure binary compatibility for KEXTs. Adding a new API breaks this. Adding new behaviour to an existing API doesn't break this, unless someone insists on using the new behaviour. If we went around adding APIs willy-nilly, then there would be no reason to have the KPIs ins the first place, and there would be no guarantees for KEXT authors, and we'd be back in the same boat we were in before the KPIs, which would not be a Good Thing(tm) for most KEXT developers - or us. However - adding behaviours to an existing API, and then not documenting them except to people who have need of the new behaviours, works around the problem with the least overall impact: the KEXTs still load because they don't have symbol set mismatches that would prevent them from being linked into the kernel, and KEXTs that don't use the new behaviour stay forward-compatible. KEXTs which *do* use the new behaviour can protect themselves, either by checking the error code and using fall-back code to do the same thing, or by insisting that the kernel version be 10.4.2 or later (or whatever version the new behaviour surfaced in). Thinks like sockopt, ioctl, fcntl, etc., especially lend themselves to this type of change because they effectively MUX points that de-MUX based on command value, and can return an error code if the command us unimplemented. - this is not documented in the latest available documentation or headers. If this is not documented, this does not exist. You should generally treat it as if it didn't exist, unless there is *no other way* to solve your problem. If you choose to use the new behaviour because of performance, you should check the error code and provide a fallback path that, even if it's not as performant, will not cause your software to stop working. If you choose to use the new behaviour because there's no other way to solve your problem, then you should ensure that your KEXT insists on a more stringent than normal version number match, and you should ship separate KEXTs for 10.4.2 and pre-10.4.2 (or resign yourself to support calls in which you tell your users to upgrade to 10.4.2 or later). This email sent to site_archiver@lists.apple.com