Re: File Access with VFS
Re: File Access with VFS
- Subject: Re: File Access with VFS
- From: "Scott Lance" <email@hidden>
- Date: Thu, 10 Apr 2003 08:18:05 -0700
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" <email@hidden>
>
To: "Darwin Kern Dev" <email@hidden>
>
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".
>
>
<http://developer.apple.com/technotes/tn/tn2028.html>
>
>
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 | 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.
_______________________________________________
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.