Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: KUNCUserNotifications, just a configd crasher?

On Wednesday, December 4, 2002, at 04:44 AM, Bernd Lvhr wrote:
It was hard in the first place to get any information about the KUNC staff!
If you implement an API - please document it - and please don't tell everybody to not use it!
All you said against the use of KUNC you should have mentioned in that (then missing) documentation long ago!

If you noticed, only IOKit interfaces [and to some extent network KEXT facilities] are really documented to have a formal API at the kernel extension level. This is on purpose! And the KUNC facility is not documented as part of those IOKit APIs, because it is NOT part of those APIs.

When we implement an API, we document it, support it, etc... When we implement an SPI, we do not. We do not have a formal set of APIs for other kinds of KEXTs. What we do have is a set of system services (SPIs) that many people use (and are mostly found through open source) for these other kinds of KEXTs. We understand that many people (including ourselves) *want* us to have a formal, sustainable API for other kinds of KEXTs. But it just doesn't exist. We are working on defining those now and have, and continue to, solicit input on what kinds of services people need in that API.

We also understand that even though many of those other interfaces are only SPIs, we have a larger than usual support burden because there was no alternative for such a long time. But please don't demand that we treat them as API. They are not.

Of course one could install a daemon which polls the driver for any user relevant information, but I dislike polling and each little app has to be documented, supported, installed, uninstalled, localized etc. which adds to the cost of development.

We [I] dislike polling as well. But it isn't really "polling" when you only have to do it once (i.e. request to be told when an event occurs and then wait forever until that event notification comes in). The "polling" we dislike is the classic "Are we there yet?" kind of repetitive queries. Much different.

In fact, our public APIs pretty much insist on a passive model for the kernel, where data is "pulled" out by user-level threads. You may dislike this model, and it is different than Classic Mac OS 9.x extensions, but it was chosen very carefully. Given a preemptively scheduled kernel, supporting realtime user-level threads with limited resources, we don't want to have to throw events on the floor for upward flow-control reasons. By "polling" down from user-level for the current state, rather than pushing up each individual state change, the effect of missed state transitions is minimized (while still allowing realtime threads to run even if the mouse button is down, to state an overly simplistic but illuminating example).

As for each little app adding to the cost,... it has to be paid one way or another. The KUNC messages have to be localized anyway (as you mentioned). The IOKit model is to include the helpers as part of the KEXT bundle, so there really isn't any additional component to install. It just requires thinking a little different. But doing so will allow us to steer you around those future obstacles that you don't even know are coming (but we do - which is why we didn't publish that other SPI in the first place).

--Jim
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: KUNCUserNotifications, just a configd crasher? (From: Bernd Löhr <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.