Re: opening files in the kernel
Re: opening files in the kernel
- Subject: Re: opening files in the kernel
- From: Chris Bergmann <email@hidden>
- Date: Tue, 24 Feb 2004 19:11:12 +1000
Generally if you need to read/write to files from a KEXT in mass, you
use
the IOKit messages or sockets or sysctl depending on what you're doing
to
a user daemon to do file IO.
Probably not suitable in this instance; i'm sitting a little too
low-level to try this.
As a basic background to where i'm coming from- I've converted Apple's
HFS+ code to compile with C++ and made the necessary modifications to
run as a KEXT; now i'm trying to create some additional "system"
files.
I'm baffled why you converted this to C++, file systems are not IOKit
objects, and are generally C only entities.
KEXTs support C++. I like C++. In this particular case, the one thing
which caused me to convert it to C++ is the ability to then namespace
the whole KEXT. Having namespace conflicts between Apple's in-kernel
HFS+ and my kext built from [originally] the same source was Not Fun.
That's fixed now. You could do this in straight C with a bit of work,
however i'm mainly playing and learning and this technique suited me.
Apple's existing system files (extents tree, etc) are treated rather
specially by the filesystem and I don't want to go down the same path-
instead I would like to open a file in much the same way as a userland
process would (except using the vfs directly since i'm in a KEXT.)
This is generally considered a bad thing to do. The locking issues are
complex in a file system and you can easily bypass a lot of the locking
rules by accessing these functions out of context. Its incredably
easy to
leave a vnode locked somewhere and not have the system panic till much
later on.
Yes, i realise. That's pretty much what i'm looking for information on.
What are you trying to accomplish anyways? If you really are trying to
add another file to the "special" area of HFS+ in CNID's 2 though 15
then
I'd imagine you'd probably have to make your own HFS+ file system and
build that into a new kernel, or try to make it a loadable file system
and
put it at a higher priority for HFS in the filesystem bundles. Either
way
this can get quite annoying pretty quickly.
I've got my own HFS+ file system, it's a runtime loaded kext, it works.
I'm now trying to make some modifications. I require additional storage
space for extra data that the modifications will require. This storage
space is equivalent to the extents-tree and other system files. I could
take the exact same approach that apple does for the extents tree,
journalling files, etc, however I don't see any way of doing that
without breaking compatability with the on-disk HFS format. There
appears to be a preset number of system files which have their extents
stored in the master blocks. I didn't see any [compatible] way of
extending that, therefore i'm trying to open a "normal" file after the
end of the normal HFS+ mount sequence.
If there is some 'hfs-compatible' technique for extending the number of
actual system files (the ones with their extents stored in the master
block) then please let me know and i'll go do that and save myself the
hassle..
thx,
chris
_______________________________________________
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.