Re: kern_control question
Re: kern_control question
- Subject: Re: kern_control question
- From: Terry Lambert <email@hidden>
- Date: Fri, 19 Aug 2005 13:45:42 -0700
On Aug 19, 2005, at 2:33 AM, Stephane Sudre wrote:
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 agree to the first statement: there's no fast way, unless the kext
checks the soft version number and fails to load itself. As to the
question: the KEXT gets an error return from a function call, and
handles it properly...
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?
Because there isn't a restriction unless you use an undocumented
interface extension. 8-).
So you can:
(a) get load-time notification so the kext can go into fall-back mode
without having to "try it first"
(b) get try-time notification, and do a lazy-fallback
(c) get a load-refusal if the version isn't high enough, and you
don't have a fallback
(d) not use the extension and not worry about it
Actually, the worst thing that's been said in this whole thread is
documentation of an undocumented interface extension -- you should
have had to contact DTS for the information, and been told about your
options on using it so this whole thing wouldn't show up in a search
engine some place, where people don't read the whole discussion, and
decide to use it, not knowing the restrictions.
-- 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