| Thanks Shantonu,
Ok, I won't use a timeout.
As for decoupling, that's a mechanism I'm not confortable with currently, so I'd rather avoid the possibility of introducing more bugs.
In case of a Safe Boot, I won't need access to the NVRAM, so it does not apply.
Thank you all, Antoine
On 2011-06-30, at 8:53, Shantonu Sen wrote: I don't think our advice is inconsistent. You asked if you could depend on your attached code. I said a 20 second timeout can fail. Mike said don't bother setting a timeout. The net advice is to not use a timeout.
I further advised that blocking in your start() routine is generally poor form, and if you can, decoupling your initialization might be useful. In your case, your kext would start even in safe boot mode, but likely would not access hardware until it knew that it should.
Shantonu On Jun 30, 2011, at 5:47 AM, Antoine Missout wrote: Mike,
I agree with you, and thanks for the suggestion for the code (and yes, I use a unique IOMatchCategory), yet Shantonu wrote:
No you cannot. If some other kext has the same clever idea to block in their start() routine while matching on IOResources, it will prevent the NVRAM driver on Mac OS X from starting, which will in turn cause your kext to fail. And that's one of the reason for the timeout - preventing a deadlock if some weird situation I don't know of comes up. Now I'm stuck with two conflicting advices.
Regards, Antoine
On 2011-06-30, at 4:27, Michael Smith wrote:
Antoine,
You should specify IOBSD in your IOResourceMatch, and then use IOService::waitForMatchingService to wait for IODTNVRAM. It will always be present under normal circumstances. It's not useful specifying a timeout for this sort of thing, when you're waiting for something that will always show up - at most it will make your kext fail in odd situations when you don't normally expect it to (e.g. when debugging...)
In general, if you have multiple dependencies, use IOResourceMatch on something that will get you instantiated when it's appropriate, then use IOService::waitForMatchingService to wait for the rest of your dependencies to show up.
If you are using something common like IOBSD or IOResources for your IOResourceMatch, make sure that you're a good citizen and specify a unique IOMatchCategory so that you don't block others that are also trying to match at the same time.
= Mike On Jun 29, 2011, at 11:50 AM, Antoine Missout wrote: Ok, how can I specify both IOBSD and IONVRAM in IOResourceMatch to do so ?
Specifying only IONVRAM does not seem to guarantee IOBSD. I could not find any doc or example having multiple dependencies.
- Antoine
On 2011-06-29, at 12:32, Shantonu Sen wrote: No you cannot. If some other kext has the same clever idea to block in their start() routine while matching on IOResources, it will prevent the NVRAM driver on Mac OS X from starting, which will in turn cause your kext to fail.
What are you really trying to do? Almost certainly the correct answer is to set up an asynchronous notification for arrival of NVRAM, and defer initialization until it is available. Another option, depending on what you're really trying to do, is to express your IOKit personalities so that you depend on the NVRAM kext being started, which will cause your kext to be started no earlier than it.
-- Excellence in any department can be attained only by the labor of a lifetime; it is not to be purchased at a lesser price -- Samuel Johnson
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
|