Re: kern_control question
Re: kern_control question
- Subject: Re: kern_control question
- From: Terry Lambert <email@hidden>
- Date: Thu, 18 Aug 2005 16:15:04 -0700
On Aug 18, 2005, at 2:18 AM, Stephane Sudre wrote:
On 17 août 05, at 22:16, Vincent Lubet wrote:
Peter,
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?
Because:
- 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).
-- Terry _______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden