Writing to a file

[Diomidis Spinellis]

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