Re: Kext fails to load when falloc is used
Re: Kext fails to load when falloc is used
- Subject: Re: Kext fails to load when falloc is used
- From: Terry Lambert <email@hidden>
- Date: Wed, 26 Apr 2006 10:36:16 -0700
On Apr 26, 2006, at 9:11 AM, Brian Bergstrand wrote:
On Apr 26, 2006, at 7:44 AM, Sudarshan S wrote:
I am trying to use falloc( ) call to mimic file open operation in
the kext on 10.4.4 kernel. The loader fails to load kext as it can
not resolve the symbol even though the symbol exists in
mach_kernel. Is it something to do with specifying proper
dependancies in 'OSBundleLibraries' section of info.plist ?
-Leo
falloc is not a supported KPI, therefore you'd have to link against
the kernel proper (using OSBundleLibraries), but in doing so you
limit your KEXT to that specific version of the kernel - neither
earlier or later versions will work. If you plan on shipping the
KEXT to third-party users this is a bad idea.
The specific issue for falloc() is that it's a middle-tier function in
which we implement locking of the per process open file table. We
need to reserve the right to change the locking paradigm between point
releases, both to fix any issues that users run into, and for
performance or other reasons. The falloc() function also has the
issue that it externalizes the struct fileproc pointer - this is a
kernel internal structure, which we reserve the right to change the
layout - again, either to fix problems, or for performance or other
reasons.
Because of this, we avoid externalizing the falloc() or falloc_locked
() functions.
If you absolutely need to be able to rendezvous with a file descriptor
(e.g. either through a fork() or a fork(0 and a pass of /dev/fd/XXX on
the command line as a security precaution, or through using UNIX
domain sockets), then you need to create a device, a pseudo-device, a
file system, or a protocol family/socket type to externalize the fd
through normal channels. This will avoid the need to use such
functions directly.
Also, reading/writing to file from a KEXT is highly discouraged. It
can lead to all kinds of problems. Better would be to create a
userland daemon that acts as a proxy for the kext.
This is also correct.
When you do anything that might be on the paging path or some other
code path that would reference itself through its normal operation,
you risk a deadlock at best, or a system panic at worst. The proper
approach to this is to create a (pseudo-)device, parse the information
in user space in user space code to avoid bringing a large parser into
wired memory in the kernel, and then ioctl() down the minimal possible
information, as a pre-agreed upon format binary blob, to the (pseudo-)
device driver, which then uses it (e.g. to download firmware for a PCI
card, etc.).
-- 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