Re: user settable preferences for a kext
Re: user settable preferences for a kext
- Subject: Re: user settable preferences for a kext
- From: Dean Reece <email@hidden>
- Date: Wed, 17 Dec 2003 11:17:10 -0800
On Dec 17, 2003, at 5:12 AM, Stefan Werner wrote:
how can I have preference files for my kext that a "mortal"
(=non-root) user can write? Is there a way a kernel extension can
safely read .plist files in /Library/Preferences?
The over-arching rule is that kexts should not have preferences. They
can have modes/state that are set by their clients while in use. The
introduction of global persistent preferences for a kext introduces a
file that can become corrupt and must be maintained. The kext must
always be able to do something reasonable if this file is missing or
corrupt, so if you are already going to the trouble, you may as well
eliminate the fragile state and always do something reasonable. A few
alternative approaches:
1) Figure out a way to not need the prefs in the first place.
2) Move out of the kernel and do your work as a daemon instead of a
kext.
3) Have the driver not maintain prefs, but instead have the client app
push the prefs down on open.
If none of these approaches will work for your product, then the only
supported way is to have a daemon that coordinates all file I/O for
your driver. The daemon launches at boot and searches the IORegistry
for instances of your driver and uses getProperty/setProperty or your
own IOUserClient to push the data down. For non-IOKit kexts, you'll
have to work out your own rendezvous mechanism between the kext and the
daemon (socket or a /dev node are good choices)
Right now, I am using the kext's Info.plist to pass preferences to my
kext, but that file can only be written by root.
This is not supported, and will work differently (or not at all) on
different versions of Mac OS X. The Info.plist file is considered part
of the driver, and not a prefs database. For performance reasons, it
is often cached, so changes you make to the Info.plist may not be
noticed by the driver until the cache gets rebuilt. Future versions of
the OS my detect the change in the driver and flag it as potentially
corrupt. In short, don't do this in production code - it is OK for
development & testing in a controlled environment only.
Cheers,
- Dean
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.