I looking at the kthread_create() call and wondering when the use of
threads in the kernel is reasonable.

Now, of course kernel threads aren't reasonable if something really needs
to be handled by an interrupt. Granted. And data brought in from, say, a
chip needs to make it to somewhere during an interrupt. This is what queues
are for. Granted.

But what about after that? What MUST be handled by the bottom half of the
kernel and not in a thread?

You may ask yourself "Where in the heck is he going with this?"

I was looking at tracking down some bugs in the ppp driver. Now, trying
to figure out where in the heck the ppp driver gets off course is a real
trick. Part of it runs in a process context, part in an interrupt context,
and part in a callout. The tricky part is that the functions called by
the three cases are the *same* functions. And these functions shared by
all three cases are the functions that schedule interrupts, callouts, etc.

Yikes. 

I was considering rewriting the in kernel ppp code to instead use a pair
of threads. Data comes into one thread (from the tty), data goes out (to
the tty) in the other thread. Is that reasonable?

It would break the code into two distinct paths with very little overlap.
It would be nice and clear to read, and would be trivial (or easy) to make
SMP safe.

Would it introduce additional latency? Is it possible to send and receive
data from a network interface while in the top half of the kernel? Would
I run into problems with threads having to wake up every so often to
attempt to retransmit?

Am I off my rocker? (At least a minimal "beauty!" or "yuck!" would be much
appreciated.)
-- 
Kevin P. Neal                                http://www.pobox.com/~kpn/

Seen on bottom of IBM part number 1887724:
DO NOT EXPOSE MOUSE PAD TO DIRECT SUNLIGHT FOR EXTENDED PERIODS OF TIME.