Discussion:
Writing a plain text file to disk from kernel space
(too old to reply)
Lawrence Stewart
2007-05-15 04:18:37 UTC
Permalink
Hi all,

I'm in the process of writing a kernel module to instrument some parts
of the network stack in FreeBSD 6.2. Everything works perfectly, except
that writing the logging info to syslog using printf is too inefficient
for this particular task. Given that log messages need to be generated
for each packet entering/leaving the network stack, my testing thus far
has showed that syslog groans under the load and uses far too much CPU time.

So, I'm looking for a way to manually open up a file from within kernel
space and dump characters into it.

I've come across the following threads that are related to my problem:

http://lists.freebsd.org/pipermail/freebsd-hackers/2007-May/020330.html

http://lists.freebsd.org/pipermail/freebsd-fs/2005-September/001306.html

Neither thread has provided the "ah-ha" information/discovery I'm
needing to get this working, and so I'd be very grateful to anyone that
can shed some light on how to piece this together in the most efficient
way possible.

To summarise the things I've experimented with thus far:

1. Following the "open" syscall down into kernel land and investigating
how the underlying kernel functions work. The "kern_open" function in
"kern/vfs_syscalls.c" seems interesting.

However, all of interesting functions that I've found take a thread
struct pointer as the first argument. I have not been able to figure out
where to get a thread struct pointer from. So perhaps if someone can
shed light on how to go about creating a thread struct suitable for
passing to these functions, I may be able to figure it out. I've tried
creating a new kthread using kthread_create, and got this working, but
this still didn't give me access to a thread struct pointer. I've also
tried accessing the thread queue for process 0 but didn't have any luck
there either (though I could have been accessing it incorrectly!).

2. Following the kernel panic code where it writes a dump out to disk.
This uses very scary low level structs and functions that I couldn't
wrap my head around... appeared to be below the vfs layer in the kernel,
so I suspect its to far below where I want to be at.

3. I followed the ktrace code, but that seemed to lead to a dead end of
passing logging data up to userspace via the ddb subsystem, which is not
what I want to do.

4. I followed coredump code, and this looked very interesting. It
operates directly on vnodes, but once again, the elusive thread struct
pointer is needed.



The "kern/vfs_*" files seem to contain the functions relating to all the
action of creating/writing/reading files (vnodes)... is there a good
document/tutorial somewhere that describes the layering and various
abstractions in the FreeBSD kernel fileystem related code? TCP
Illustrated has been invaluable in describing the layout and structure
of the various network stack components/functions/structs in the kernel.
Something similar for filesystem related tasks would be most useful.

I suspect that once I understand the mechanics of where thread struct
pointers come from and how to get my hands one one from within the
kernel, I'll be able to get the rest going.

Many thanks for your time and help.

Regards,
Lawrence Stewart
Marc Lörner
2007-05-15 06:47:38 UTC
Permalink
Hello Lawrence,

in file kern/vfs_syscalls.c you can see the kern_open function that uses
vn_open to open a file/vnode.

There are more vn_* functions like vn_rdwr for reading and writing to a vnode
or vn_close to close a vnode. To see how theses functions work, I suggest you
grep for them in the kernel-files.

BTW, you can get an thread-struct pointer from curthread (c.f. sys/pcpu.h).

HTH,
Marc Lörner
Lawrence Stewart
2007-05-15 11:08:01 UTC
Permalink
Hi Marc,


Marc Lörner wrote:

[snip]
Post by Marc Lörner
BTW, you can get an thread-struct pointer from curthread (c.f.
sys/pcpu.h).
[snip]


Thanks very much for the reply.

"curthread" is the missing key that I've been looking for! Thank you so
much. I've been banging my head against a brick wall for days now.

I'll have a play around and report back to the list what I find for
archival purposes.

Cheers,
Lawrence

PS Just found a thread I hadn't found before
(http://lists.freebsd.org/pipermail/freebsd-hackers/2006-March/015647.html)
which has lots of useful info and a link
(http://people.freebsd.org/~pjd/misc/kernio/) to some sample code!
Ivan Voras
2007-05-17 23:11:44 UTC
Permalink
Post by Lawrence Stewart
I'll have a play around and report back to the list what I find for
archival purposes.
Please do, and also consider writing a short and instructive tutorial on
it! Many people have asked this same question without a to-the-point answer.
Lawrence Stewart
2007-05-21 08:52:48 UTC
Permalink
Will do Ivan as soon as I've figured everything out.

However, I need some more help from you knowledgeable people.

Attached is a fully self contained kernel module and associated makefile
that demonstrates the problem I'm having. I've also attached a compiled
version of the module for FreeBSD 6.2 RELEASE.

The module does the following:

- In its init function, it opens a file descriptor to /var/log/test23.log
- In its init function, it writes a line of text to the opened file
descriptor
- In its shutdown function, writes a line of text to the opened file
descriptor
- In its shutdown function, closes the opened file descriptor

The opening of the file descriptor and writing of text done in the
module's init function works as expected.

The writing of text done in the shutdown function fails with an errno of
9 (bad file descriptor) returned. The closing of the file descriptor
doesn't appear to return an error, but I suspect it isn't working either.

From what I've deduced so far, it appears to be a thread related issue.
I have verified that the thread struct pointer pointed to by "curthread"
in the module's init function is different to that in the shutdown function.

I suspect that you can't use a file descriptor that was opened in one
thread in a completely different thread, but I'm not sure if this is
true, and if it is true, how to get around it.

Any ideas, explanations, help or suggestions regarding how file IO and
threading work and how I can get cross-thread file IO working would be
most welcome.

Cheers,
Lawrence
Post by Ivan Voras
Post by Lawrence Stewart
I'll have a play around and report back to the list what I find for
archival purposes.
Please do, and also consider writing a short and instructive tutorial
on it! Many people have asked this same question without a
to-the-point answer.
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
Dag-Erling Smørgrav
2007-05-21 10:58:34 UTC
Permalink
Post by Lawrence Stewart
I suspect that you can't use a file descriptor that was opened in one
thread in a completely different thread, but I'm not sure if this is
true, and if it is true, how to get around it.
A file descriptor is an index into a file table. Different threads have
different file tables.

If you want to read from or write to files within the kernel, you need
to operate directly on vnodes, not on file descriptors.

DES
--
Dag-Erling Smørgrav - ***@des.no
Lawrence Stewart
2007-05-22 08:45:00 UTC
Permalink
OK well that's cleared up. Thanks DES.

So I went back to trying the kernio code I found here
(http://people.freebsd.org/~pjd/misc/kernio/) which does operate
directly on vnodes (first time I tried it I was getting kernel panics,
so I assumed the code was a bit dated and carried on down the path of
trying to get file descriptors working).

Anyways, I modified the filewriter kernel module that I attached to my
previous post so that it used the kio code, and verified that the code
does work when called across different threads (in the module's init and
deinit functions). However, when I ported it into my other module that
I'm actually working on that uses the pfil hooks, I started getting hard
resets again.

After further investigation, it turns out that the pfil input hook I'm
using, which catches packets as they traverse up the network stack, has
no problems, and will happily write to the file using the kio_write
function. However, in the pfil output hook, a call to kio_write causes a
hard reset, with the following text shown on tty0:

Sleeping thread (tid 100069, pid 613) owns a non-sleepable lock
panic: sleeping thread

If I comment out the kio_write code and put a printf instead, there are
no such problems, so it seems the kio_write function is doing something
that is upsetting the kernel, but only when called from a function that
is acting as a pfil output hook? Strikes me as odd behaviour. I don't
understand which thread the error is in relation to, why that thread is
sleeping or which lock it is referring to.

I tried wrapping the call to kio_write in a mutex, in case there was a
race condition caused by multiple threads trying to write to the file at
the one time, but that hasn't made a difference at all.

I've attached the code that demonstrates the problem, but be warned:
I've intentionally left it in a state that demonstrates the problem, and
it will therefore hard reset any machine you run it on.

Any thoughts on what's going on and how I can make the kio code not
break the kernel when called from within a function that is acting as a
pfil output hook?

Cheers,
Lawrence
Post by Dag-Erling Smørgrav
Post by Lawrence Stewart
I suspect that you can't use a file descriptor that was opened in one
thread in a completely different thread, but I'm not sure if this is
true, and if it is true, how to get around it.
A file descriptor is an index into a file table. Different threads have
different file tables.
If you want to read from or write to files within the kernel, you need
to operate directly on vnodes, not on file descriptors.
DES
Dag-Erling Smørgrav
2007-05-22 09:18:08 UTC
Permalink
Post by Lawrence Stewart
After further investigation, it turns out that the pfil input hook I'm
using, which catches packets as they traverse up the network stack,
has no problems, and will happily write to the file using the
kio_write function. However, in the pfil output hook, a call to
Sleeping thread (tid 100069, pid 613) owns a non-sleepable lock
panic: sleeping thread
This is a panic, not a hard reset.

Since you are writing kernel code, I assume you have KDB/DDB in your
kernel and know how to use it.
Post by Lawrence Stewart
If I comment out the kio_write code and put a printf instead, there
are no such problems, so it seems the kio_write function is doing
something that is upsetting the kernel, but only when called from a
function that is acting as a pfil output hook? Strikes me as odd
behaviour. I don't understand which thread the error is in relation
to, why that thread is sleeping or which lock it is referring to.
kio_write probably blocks waiting for the write to complete. You can't
do that while holding a non-sleepable lock.
Post by Lawrence Stewart
I tried wrapping the call to kio_write in a mutex, in case there was a
race condition caused by multiple threads trying to write to the file
at the one time, but that hasn't made a difference at all.
It complains about sleeping with a non-sleepable lock held, and your
solution is to add another non-sleepable lock?

DES
--
Dag-Erling Smørgrav - ***@des.no
Lawrence Stewart
2007-05-23 01:25:15 UTC
Permalink
Comments inline...
Post by Dag-Erling Smørgrav
Post by Lawrence Stewart
After further investigation, it turns out that the pfil input hook I'm
using, which catches packets as they traverse up the network stack,
has no problems, and will happily write to the file using the
kio_write function. However, in the pfil output hook, a call to
Sleeping thread (tid 100069, pid 613) owns a non-sleepable lock
panic: sleeping thread
This is a panic, not a hard reset.
Since you are writing kernel code, I assume you have KDB/DDB in your
kernel and know how to use it.
I don't know how to use them really. Thus far I haven't had a need for
really low level debugging tools... seems that may have changed though!
Any good tutorials/pointers on how to get started with kernel debugging?
Post by Dag-Erling Smørgrav
Post by Lawrence Stewart
If I comment out the kio_write code and put a printf instead, there
are no such problems, so it seems the kio_write function is doing
something that is upsetting the kernel, but only when called from a
function that is acting as a pfil output hook? Strikes me as odd
behaviour. I don't understand which thread the error is in relation
to, why that thread is sleeping or which lock it is referring to.
kio_write probably blocks waiting for the write to complete. You can't
do that while holding a non-sleepable lock.
So this is where my knowledge/understanding gets very hazy...

When a thread blocks waiting for some operation to complete or event to
happen, the thread effectively goes to sleep, correct?

Looking at the kio_write code in subr_kernio.c, I'm guessing the lock
that is causing the trouble is related to the "vn_lock" function call?

I don't understand though why the vnode lock would be set up in such a
way that when the write blocks whilst waiting for the underlying
filesystem to signal everything is ok, it causes the kernel to panic!

How do I make the lock "sleepable" or make sure the thread doesn't try
go to sleep whilst holding the lock?
Post by Dag-Erling Smørgrav
Post by Lawrence Stewart
I tried wrapping the call to kio_write in a mutex, in case there was a
race condition caused by multiple threads trying to write to the file
at the one time, but that hasn't made a difference at all.
It complains about sleeping with a non-sleepable lock held, and your
solution is to add another non-sleepable lock?
I didn't realise and don't understand why a mutex is considered a
non-sleepable lock? Reading the mutex man page, it seems clear that
creation of a standard mutex can indeed allow an interrupt or other
kernel event to preempt the current thread holding the mutex, and
therefore allow the thread to sleep whilst the higher priority event is
handled? Doesn't sound like it's non-sleepable to me, but I could very
well be misunderstanding the terminology.


All of that aside, why don't I get a "sleeping thread" panic when only
the pfil input hook is put in place? If I was getting the panic when
either an input or output hook was set, I wouldn't be so perplexed. But
the fact that I only see this panic behaviour when the output hook
(catching packets travelling down the network stack) is installed
doesn't seem to add up. Any ideas?

Cheers,
Lawrence
Lawrence Stewart
2007-05-23 02:24:18 UTC
Permalink
To add another interesting bit to the puzzle... if I install both input
and output pfil hooks, and use ping to generate network traffic, the
writing to file in both the input and output hook works perfectly as
well - even at high packet rates. Here's the weird bit: the second I try
and initiate a TCP connection, I get a kernel panic.

So it seems that it is only when I generate TCP outbound traffic that
the kernel panic happens. If I telnet to a closed port on a valid IP, I
don't get a panic. If I telnet to an open port on a valid IP, it doesn't
panic until I attempt to send the first bit of user data down the
socket... so it seems that it's panicing on threads that are sheparding
outbound TCP user data through the kernel. Outbound TCP SYN and ACK pkts
used in the 3 way handshake to establish TCP connection don't cause the
panic.

To me, that says that there is something funky going on with the threads
that TCP connections use when sending packets down through the network
stack.

Can anyone shed some light on why threads that handle the processing of
outbound TCP packets containing user data would cause a vnode write to
fail because of a sleeping thread issue? From what I can gather, there
must be some difference in the way the threads are created/configured...
but I have no idea where to start looking to figure out what's going on
here.

Cheers,
Lawrence
Dag-Erling Smørgrav
2007-05-23 07:51:04 UTC
Permalink
Post by Lawrence Stewart
Post by Dag-Erling Smørgrav
Since you are writing kernel code, I assume you have KDB/DDB in your
kernel and know how to use it.
I don't know how to use them really. Thus far I haven't had a need for
really low level debugging tools... seems that may have changed
though! Any good tutorials/pointers on how to get started with kernel
debugging?
The handbook and FAQ have information on debugging panics. Greg Lehey
(grog@) does a tutorial on kernel debugging, you can probably find
slides online (or just ask him)
Post by Lawrence Stewart
Post by Dag-Erling Smørgrav
kio_write probably blocks waiting for the write to complete. You can't
do that while holding a non-sleepable lock.
So this is where my knowledge/understanding gets very hazy...
When a thread blocks waiting for some operation to complete or event
to happen, the thread effectively goes to sleep, correct?
It depends on the type of lock used, but mostly, yes.
Post by Lawrence Stewart
Looking at the kio_write code in subr_kernio.c, I'm guessing the lock
that is causing the trouble is related to the "vn_lock" function call?
What matters is that kio_write() may sleep and therefore can't be called
while holding a non-sleepable lock.
Post by Lawrence Stewart
I don't understand though why the vnode lock would be set up in such a
way that when the write blocks whilst waiting for the underlying
filesystem to signal everything is ok, it causes the kernel to panic!
You cannot sleep while holding a non-sleepable lock. You need to find
out which locks are held at the point where you call kio_write(), and
figure out a way to delay the kio_write() call until those locks are
released.
Post by Lawrence Stewart
How do I make the lock "sleepable" or make sure the thread doesn't try
go to sleep whilst holding the lock?
You can't make an unsleepable lock sleepable. You might be able to
replace it with a sleepable lock, but you would have to go through every
part of the kernel that uses the lock and make sure that it works
correctly with a sleepable lock. Most likely, it won't.

DES
--
Dag-Erling Smørgrav - ***@des.no
Lawrence Stewart
2007-05-25 03:26:58 UTC
Permalink
Comments inline...
Post by Dag-Erling Smørgrav
Post by Lawrence Stewart
Post by Dag-Erling Smørgrav
Since you are writing kernel code, I assume you have KDB/DDB in your
kernel and know how to use it.
I don't know how to use them really. Thus far I haven't had a need for
really low level debugging tools... seems that may have changed
though! Any good tutorials/pointers on how to get started with kernel
debugging?
The handbook and FAQ have information on debugging panics. Greg Lehey
slides online (or just ask him)
For reference, I found what looks to be a very comprehensive kernel
debugging reference here:
http://www.lemis.com/grog/Papers/Debug-tutorial/tutorial.pdf

Greg certainly knows the ins and outs of kernel debugging!
Post by Dag-Erling Smørgrav
Post by Lawrence Stewart
Post by Dag-Erling Smørgrav
kio_write probably blocks waiting for the write to complete. You can't
do that while holding a non-sleepable lock.
So this is where my knowledge/understanding gets very hazy...
When a thread blocks waiting for some operation to complete or event
to happen, the thread effectively goes to sleep, correct?
It depends on the type of lock used, but mostly, yes.
Post by Lawrence Stewart
Looking at the kio_write code in subr_kernio.c, I'm guessing the lock
that is causing the trouble is related to the "vn_lock" function call?
What matters is that kio_write() may sleep and therefore can't be called
while holding a non-sleepable lock.
Post by Lawrence Stewart
I don't understand though why the vnode lock would be set up in such a
way that when the write blocks whilst waiting for the underlying
filesystem to signal everything is ok, it causes the kernel to panic!
You cannot sleep while holding a non-sleepable lock. You need to find
out which locks are held at the point where you call kio_write(), and
figure out a way to delay the kio_write() call until those locks are
released.
Post by Lawrence Stewart
How do I make the lock "sleepable" or make sure the thread doesn't try
go to sleep whilst holding the lock?
You can't make an unsleepable lock sleepable. You might be able to
replace it with a sleepable lock, but you would have to go through every
part of the kernel that uses the lock and make sure that it works
correctly with a sleepable lock. Most likely, it won't.
Thanks for the explanations. I'm starting to get a better picture of
what's actually going on.

So it seems that there is no way I can call kio_write from within the
function that is acting as a pfil output hook, because it blocks at some
point whilst doing the disk write, which makes the kernel unhappy
because pfil code is holding a non-sleepable mutex somewhere.

If you read my other message from yesterday, I still can't figure out
why this only happens with outbound TCP traffic, but anyways...

I'll have a bit more of a think about it and get back to the list shortly...

Cheers,
Lawrence
John Baldwin
2007-06-05 19:39:22 UTC
Permalink
Post by Lawrence Stewart
Comments inline...
Post by Dag-Erling Smørgrav
Post by Lawrence Stewart
Post by Dag-Erling Smørgrav
Since you are writing kernel code, I assume you have KDB/DDB in your
kernel and know how to use it.
I don't know how to use them really. Thus far I haven't had a need for
really low level debugging tools... seems that may have changed
though! Any good tutorials/pointers on how to get started with kernel
debugging?
The handbook and FAQ have information on debugging panics. Greg Lehey
slides online (or just ask him)
For reference, I found what looks to be a very comprehensive kernel
http://www.lemis.com/grog/Papers/Debug-tutorial/tutorial.pdf
Greg certainly knows the ins and outs of kernel debugging!
Post by Dag-Erling Smørgrav
Post by Lawrence Stewart
Post by Dag-Erling Smørgrav
kio_write probably blocks waiting for the write to complete. You can't
do that while holding a non-sleepable lock.
So this is where my knowledge/understanding gets very hazy...
When a thread blocks waiting for some operation to complete or event
to happen, the thread effectively goes to sleep, correct?
It depends on the type of lock used, but mostly, yes.
Post by Lawrence Stewart
Looking at the kio_write code in subr_kernio.c, I'm guessing the lock
that is causing the trouble is related to the "vn_lock" function call?
What matters is that kio_write() may sleep and therefore can't be called
while holding a non-sleepable lock.
Post by Lawrence Stewart
I don't understand though why the vnode lock would be set up in such a
way that when the write blocks whilst waiting for the underlying
filesystem to signal everything is ok, it causes the kernel to panic!
You cannot sleep while holding a non-sleepable lock. You need to find
out which locks are held at the point where you call kio_write(), and
figure out a way to delay the kio_write() call until those locks are
released.
Post by Lawrence Stewart
How do I make the lock "sleepable" or make sure the thread doesn't try
go to sleep whilst holding the lock?
You can't make an unsleepable lock sleepable. You might be able to
replace it with a sleepable lock, but you would have to go through every
part of the kernel that uses the lock and make sure that it works
correctly with a sleepable lock. Most likely, it won't.
Thanks for the explanations. I'm starting to get a better picture of
what's actually going on.
So it seems that there is no way I can call kio_write from within the
function that is acting as a pfil output hook, because it blocks at some
point whilst doing the disk write, which makes the kernel unhappy
because pfil code is holding a non-sleepable mutex somewhere.
If you read my other message from yesterday, I still can't figure out
why this only happens with outbound TCP traffic, but anyways...
I'll have a bit more of a think about it and get back to the list shortly...
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.
--
John Baldwin
Lawrence Stewart
2007-06-06 02:25:52 UTC
Permalink
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
Post by John Baldwin
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.
Lawrence Stewart
2007-06-25 05:08:53 UTC
Permalink
Post by Ivan Voras
Post by Lawrence Stewart
I'll have a play around and report back to the list what I find for
archival purposes.
Please do, and also consider writing a short and instructive tutorial
on it! Many people have asked this same question without a
to-the-point answer.
Hi all,

Finally managed to wrap up the code and documentation for the little
module I've been working on at work. We've released the SIFTR
(Statistical Information For TCP Research) code under a BSD licence, and
hope some of you may find it useful. It's a tool mostly aimed at the TCP
research community, but perhaps someone out there might find another use
for all or part of the code. We've also made a prototype module (named
filewriter) available that specifically demonstrates file writing from
within the kernel. It should hopefully provide a useful reference
implementation for anyone wanting to write files from within the kernel.

As promised, we've also made a technical report available that documents
what we learnt whilst transitioning from noob kernel hackers to guys
that have a (partial) clue. The report is certainly a useful reference
for us and people working at our research centre. We hope it will also
be a useful reference for the community to point people at who are new
to kernel hacking. The report's title is "An Introduction to FreeBSD 6
Kernel Hacking" and has been released as Centre for Advanced Internet
Architectures Technical Report 070622A.

The code distributions and technical report can be grabbed from
http://caia.swin.edu.au/urp/newtcp/ under the "Tools" and "Papers"
sections respectively.

Many thanks to all of you who helped us make it to the finishing post
with your invaluable information and insights.

If you find a use for the code or any bugs in the code/documentation,
we'd be very happy to hear from you.

Cheers,
Lawrence

PS Is there anywhere else other than hackers@, net@, fs@ and doc@ that
might be interested in this information?

Dag-Erling Smørgrav
2007-05-15 10:32:48 UTC
Permalink
Post by Lawrence Stewart
I'm in the process of writing a kernel module to instrument some parts
of the network stack in FreeBSD 6.2. Everything works perfectly,
except that writing the logging info to syslog using printf is too
inefficient for this particular task. Given that log messages need to
be generated for each packet entering/leaving the network stack, my
testing thus far has showed that syslog groans under the load and uses
far too much CPU time.
So, I'm looking for a way to manually open up a file from within
kernel space and dump characters into it.
Look at the ktrace code.

Note that it opens the file in userland and passes it down to the
kernel. You may want to consider a similar mechanism.

DES
--
Dag-Erling Smørgrav - ***@des.no
Joseph Koshy
2007-05-21 11:06:45 UTC
Permalink
ls> So, I'm looking for a way to manually open up a file from within
ls> kernel space and dump characters into it.

des> Note that it opens the file in userland and passes it down to the
des> kernel. You may want to consider a similar mechanism.

hwpmc(4) takes a similar approach, using a dedicated kthread to
to perform writes.
--
FreeBSD Volunteer, http://people.freebsd.org/~jkoshy
Continue reading on narkive:
Loading...