Re: [PATCH] Add the ability to layer another driver over the serial driver

[Corey Minyard <cminyard@mvista.com>]

Alan wrote:
> On Mon, 11 Dec 2006 08:52:20 -0600
> Corey Minyard <cminyard@mvista.com> 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
issue.
>   
>> 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.

-Corey