Re: kern_control question
Re: kern_control question
- Subject: Re: kern_control question
- From: Stephane Sudre <email@hidden>
- Date: Fri, 19 Aug 2005 11:33:04 +0200
On 19 août 05, at 1:15, Terry Lambert wrote:
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.
[...]
I think we're seeing the problem from 2 different sides: you're seeing
it from the point of view of a person who knows a specific behavior
only works from a specific release of the OS while I'm seeing it from
the one of a person who would not know about it and consider that the
behavior available on a specific release is available to previous
releases.
From my side, if the kernel does not load, then it quite clearly
indicates where the problem lies as:
- it will just not work
- the missing API will be listed in the list of missing symbols
On the other side:
- the kernel will load
- there's no fast way to know where a problem lies if something bad
happens. Since it's working on 10.4.2, why would someone automatically
suspect where the problem is?
I do agree on the version restriction. But this is somehow an egg and
chicken problem as how would you know you need a restriction when
there's no way to know there is one?
_______________________________________________
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