RE: File Access with VFS
RE: File Access with VFS
- Subject: RE: File Access with VFS
- From: Quinn <email@hidden>
- Date: Thu, 10 Apr 2003 13:06:30 +0100
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_tutorials/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.