Writing a plain text file to disk from kernel space

Lawrence Stewart lstewart at room52.net
Wed Jun 6 02:25:53 UTC 2007


Hi John,

Thanks for the reply and additional information on locks.

The solution I've just completed working on is designed exactly as you 
describe. We're about to begin testing and evaluating the module, and 
we'll be releasing the code and 2 technical reports related to it within 
the coming weeks with any luck. The first report describes the module 
and its performance characteristics... only interesting to people doing 
TCP related research with FreeBSD. The other report is a sort of "intro 
to FreeBSD kernel hacking" paper, which is a brain dump of all the 
useful lessons we've learnt throughout the process. This report is 
mostly for our benefit so we remember the lessons we learnt for next 
time, but we're hoping it will also be something useful for the 
community to point noob kernel hackers at for some introductory information.

I'll be posting to this list as soon as the code and reports are 
available, as it has been indicated by people following this thread that 
having some sort of tutorial/reference information would be useful.

Cheers,
Lawrence

John Baldwin wrote:
> Use a task to defer the kio_write() to a taskqueue.  You have to malloc state 
> (using M_NOWAIT, which can fail) to do this properly.  If you are doing this 
> for every packet, you are probably better off using malloc() to throw items 
> into a queue and having a global task that drains the queue on each execution 
> doing kio_write()'s for each object.
>
> Regarding sleepable vs. non-sleepable locks.  Getting preempted by an 
> interrupt is not considered "sleeping".  Sleeping means voluntarily yielding 
> the CPU to wait for an event such as via msleep() or a condition variable.  
> Note that interrupt handlers can acquire non-sleepable locks.  If you sleep 
> while holding a non-sleepable lock, you may have an interrupt handler that 
> can't run while it waits for some async event (like disk I/O) to complete.
>
>   



More information about the freebsd-hackers mailing list