[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <457D70A4.1000000@mvista.com>
Date: Mon, 11 Dec 2006 08:52:20 -0600
From: Corey Minyard <cminyard@...sta.com>
To: Alan <alan@...rguk.ukuu.org.uk>
Cc: Guennadi Liakhovetski <g.liakhovetski@....de>,
Tilman Schmidt <tilman@...p.cc>, linux-serial@...r.kernel.org,
Linux Kernel <linux-kernel@...r.kernel.org>,
Hansjoerg Lipp <hjlipp@....de>, Russell Doty <rdoty@...hat.com>
Subject: Re: [PATCH] Add the ability to layer another driver over the serial
driver
Alan wrote:
> On Sun, 10 Dec 2006 19:23:54 -0600
> Corey Minyard <cminyard@...sta.com> wrote:
>
>
>> Nothing has come of this yet. But we have these two requests and a
>> request from Russell Doty at Redhat.
>>
>> It would be nice to know if this type of thing was acceptable or not,
>> and the problems with the patch. The patch is at
>> http://home.comcast.net/~minyard
>>
>
> This looks wrong. You already have a kernel interface to serial drivers.
> It is called a line discipline. We use it for ppp, we use it for slip, we
> use it for a few other things such as attaching sync drivers to some
> devices.
>
> Discussions of the form "my line discipline has no way to do 'xyz'" are
> the ones that need to happen IMHO.
>
Thanks. Line disciplines did not seem suitable for what I
needed, but perhaps can be adapted.
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.
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.
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.
-Corey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists