The big picture is simply this: I am working on writing a driver for 802.11g support on Mac OS X, after reading the chip spec I found that I needed to take a firmware file and load it into the wireless card at initialization time. This must happen EVERY TIME the card is initialized (which btw seems very weird to me, I usually thought that firmware resided on the card and the only time firmware need to be loaded from outside the card is when a firmware update was applied), in any case I copied the firmware into a hardcoded byte array and wrote it onto the card. The problem with this is when a new firmware update comes out, I am going to have to go through a lengthy conversion process for the raw firmware file and then copy it into the code to run the card. What I want to do is be able to open up a firmware file when I start the driver do my conversions and load it onto the chip so all I will really have to do when the firmware update comes out is change a file name (either in the code or the filename of the firmware). In looking into this I came across the BSD functions, and yesterday looking for more answers I came across a message similar to what you just sent (basically saying that accessing these functions in a I/O Kit driver is just not a good idea). Later when I tried to access the vn_open function, my driver would not link (again something you mentioned as a problem). So my conundrum now is: what can I now do? What would be involved using the file I/O to pass this information from user space to my I/O Kit driver (and is this possible considering that I will be loading this driver at the OS boot time)?
----- Original Message -----
From: "Quinn" <eskimo1@apple.com>
To: "Darwin Kern Dev" <darwin-kernel@lists.apple.com>
Sent: Thursday, April 10, 2003 5:06 AM
Subject: RE: File Access with VFS
At 10:37 -0700 9/4/03, Scott Lance wrote:
I am working in the context of a I/O Kit Driver. I am getting access to
these file operations through the Kernel.Framework (to include vnode.h,
namei.h, uio.h, ect..), which from what I can tell is running from the
BSD
portions of the kernel (I'm not really sure how correct I am about that).
Before you start you should read the Mac OS X section of DTS Technote
2028 "Threading Architectures".
This has a short (but information dense) description of funnels.
By default, I/O Kit drivers do not operate under either of the kernel
funnels. If your I/O Kit driver has to interoperate with BSD, such
as reading a file, it must take a funnel before entering the BSD.
For network operations, you take the network funnel, and for all
other BSD operations you take the kernel funnel.
This makes your I/O Kit driver dependent on I/O Kit and BSD. BSD
provides much less of a binary compatibility guarantee than I/O Kit.
You are exposing yourself to an increased compatibility liability
when doing this. Moreover, it's vital that you express this
dependency in your KEXT's OSBundleLibraries property, so that if we
change BSD in an incompatible way your driver will refuse to load
(rather than load and panic).
<http://www.opensource.apple.com/projects/documentation/howto/html/kext_tut
o
rials/kext_dependencies.html>
Once you get past the above issues, the BSD functions to do file I/O
from in-kernel code are pretty standard. Relevant functions include:
o NDINIT -- To initialise a struct nameidata from a path.
o vn_open -- To open the file; this gives you back a vnode.
o various vnode manipulation routines, for example, vn_lock, VOP_UNLOCK
o vn_close
o VOP_READ/VOP_WRITE -- To read and write data.
This is not really an API. Your driver is basically calling a bunch
of BSD kernel functions that are exposed so that other parts of the
BSD kernel can call them. While it's likely that the overall
technique will continue to work for the foreseeable future, it's also
likely that changes will occur that break binary compatibility.
Don't say you haven't been warning (-:
Finally, there are other, bigger, problems associated with accessing
the file system from within an I/O Kit driver. The kernel has a
locking hierarchy that it uses to prevent deadlocks. Calling the top
of the kernel (the BSD file system entry points) from the bottom (I/O
Kit) inverts that locking hierarchy, and can thus lead to nasty
deadlocks. There is no general way to avoid this.
Because of these problems, Apple's advice is not to access the file
system from within an I/O Kit driver. If there is no alternative
(see below), you should limit the amount of file I/O you do. The
general rule is to move as much file I/O as possible into user space.
There are a number of alternative designs that avoid the need for
file I/O from I/O Kit. If you can explain a little of the big
picture, I may be able to suggest other, more compatible, solutions.
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
darwin-kernel mailing list | darwin-kernel@lists.apple.com
Help/Unsubscribe/Archives:
Do not post admin requests to the list. They will be ignored.
_______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.