[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.025 / U:33.684 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site