On May 5, 2007, at 10:29 PM, Diomidis Spinellis wrote:
On May 5, 2007, at 9:34 PM, Sonja Milicic wrote:
I'm working on an IO logging utility for FreeBSD as my GSoC
project, and
I have some questions about writing a kernel functions that would
open
an existing or create a new file (with the file name as a parameter,
returns a vnode * for the file) and write data to that file (with
pointer to data as parameter). I've found some functions in existing
code that do similar things and might help me understand how to
solve my
problem, but as there isn't much documentation out there I still
don't
understand a lot of things. So, could anyone please give me a
detailed
explanation of how to open a file in kernel and write to it - best
data
types to use, functions, what to look out for, maybe a link to
tutorial
or manual that deals with this (if such a thing exists), etc.?
A good strategy for dealing with such questions is to look for code
that does a task similar to the one you want to implement. Two
kernel subsystems that come to my mind is the kernel logging
facility, which writes data to a user space process via a socket,
and the process accounting facility, which writes data to an
already opened file. There are reasons (performance, flexibility)
why these two facilities have been designed in this way, and it
would be a good idea to see whether some of their design decisions
are also applicable to your problem.
Some clarifications on the above. You can find the kernel-side of
the accounting code at
/usr/src/sys/kern/kern_acct.c
acct opens an existing file for appending; acct_process (look for
vn_rdwr) will write to that file.
Similarly, you can find the kernel-side of the system log code at /
usr/src/sys/kern/subr_prf.c. The userland client, which actually
writes the message buffers to files, is at /usr/src/usr.sbin/syslogd.
In general, coding in the kernel environment is tricky. You have to
be careful with locking, many standard C facilities are missing, and
bugs can bring down the entire system. Therefore, it is often better
to split complex tasks into two: a simple part in the kernel will
communicate with a userland process, where you can put all the
complexity. Another example of this pattern is the routing code.
Diomidis Spinellis - http://www.spinellis.gr
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
