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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alan wrote:
On Mon, 11 Dec 2006 08:52:20 -0600
Corey Minyard <[email protected]> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux