[lkml]   [2006]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Add the ability to layer another driver over the serial driver
Alan wrote:
> On Mon, 11 Dec 2006 08:52:20 -0600
> Corey Minyard <> wrote:
>> So here's the start of discussion:
>> 1) The IPMI driver needs to run at panic time to modify watchdog
>> timers and store panic information in the event log. So no work
>> queues, no delayed work, and the need for some type of poll
>> operation on the device.
> That would be the existing serial console interface. For things like USB
> serial you are probably out of luck. At the moment we have a single
> "console" attached to a specific serial console interface. The code is
> almost all there for allowing other parties to create new synchronous
> serial logging devices by opening open as the console driver does.
I don't think the console interface really helps. Input processing is also
needed, and the output blocks until the character is sent. A poll routine
is a better way to accomplish this, IMHO.
>> 2) The IPMI driver needs to get messages through even when
>> the system is very busy. Since a watchdog runs over the driver,
>> it needs to be able to get messages through to avoid a system
>> reset as long as something is pinging the watchdog from userland.
> You have a high priority character output function which jumps existing
> data. Not all hardware implements this, and some of the modern hardware
> in particular simply doesn't physically support such behaviour. Also if
> you are the sole user of the port you *know* nobody else will be queuing
> data to it anyway.
That's not really the issue. The input processing is again the
>> Currently there are mutexes, lock_kernel() calls, and work queues
>> that cause trouble for these.
>> There is also a comment that you can't set low_latency and call
>> tty_flip_buffer_push from IRQ context. This seems to be due to a
>> lack of anything in flush_to_ldisc to handle reentrancy, and perhaps
>> because disc->receive_buf can block, but I couldn't tell easily.
> The entire tty side locking, scheduling and design is based upon the idea
> that input processing is deferred. Otherwise you get long chains of
> recursion from the worst cases.
I was actually wrong, flush_to_ldisc does handle reentrancy.
It can only have one caller to disc->receive_buf() at a time. So
long chains of recursion don't seem to be possible, even if called
from IRQ context.

And studying the way ppp does writing, it can bypass the tty_write()
call and directly call the drivers. So that bypasses the transmit
locking problems I saw.

This is going to require some more thought. But I believe it can be
done with adding a poll routine to the tty_operations structure and
perhaps some minor changes around tty_flip_buffer_push.

Thanks for your help.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-12-11 17:33    [W:0.059 / U:15.832 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site