site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Apr 26, 2006, at 9:11 AM, Brian Bergstrand wrote: This is also correct. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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. 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.). This email sent to site_archiver@lists.apple.com