Re: File level action protocol
Re: File level action protocol
- Subject: Re: File level action protocol
- From: Mike Smith <email@hidden>
- Date: Tue, 5 Jul 2005 18:55:37 -0700
On Jul 5, 2005, at 1:17 PM, Thomas Tempelmann wrote:
Since there seem to be a few people here knowing enough about file
systems and BSD, I like to ask this rather general question:
Consider I'd want to write a service that logs the time and path
(or node
ID) of any file that got written.
Does Tiger now provide some API that I can use from outside the
kernel or
would I still have to write a kext that hooks into the file system
stack?
You can't "write a kext that hooks into the file system stack". The
VFS KPI
is a one-to-one contract between the kernel and a filesystem; it does
not
support interposition by a third party.
What do you mean by "got written"? Created? Modfied? Do you want one
log entry for each operation, or just a summary? What do you plan to do
about files that move after they are opened? Deleted after they are
opened?
Opened twice via different paths? Not opened by path at all? Opened
on remote filesystems without persistent IDs? Opened via context-
sensitive
paths? What about device nodes? Symbolic links that change after the
file is opened? Opened via relative paths?
You can't approach this by halves; if you plan to write something that
works this closely with the system, you must understand how files
actually work.
I don't have plans to work on this right now but would rather know if
this is feasible at all in Tiger, and how difficult it would be.
Depending on what your answers to the above were, it might be fairly
easy, or quite hard.
For said logging service, I'd have to have some way to store the
information, i.e. eventually writing it to a file. If I'd have to
write a
kext - would I then be able to call the file systems below me to
write to
a file?
Not generally, no.
If not, do I have at least virtual, dynamic, memory (i.e. a
memory mapped file) so that I can at least save the data to "RAM"
until a
non-kernel service can pull the data out and save it "properly"?
It's fairly straightforward to have your non-kernel service waiting for
data all the time, so you won't have to buffer all that much in-kernel
(although be aware of the possibilities for endless recursion implicit
in this model).
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden