Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936922AbWLKQ3e (ORCPT ); Mon, 11 Dec 2006 11:29:34 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S937072AbWLKQ3e (ORCPT ); Mon, 11 Dec 2006 11:29:34 -0500 Received: from gateway-1237.mvista.com ([63.81.120.158]:50560 "EHLO gateway-1237.mvista.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936922AbWLKQ3d (ORCPT ); Mon, 11 Dec 2006 11:29:33 -0500 Message-ID: <457D876B.9000508@mvista.com> Date: Mon, 11 Dec 2006 10:29:31 -0600 From: Corey Minyard User-Agent: Icedove 1.5.0.8 (X11/20061116) MIME-Version: 1.0 To: Alan Cc: Guennadi Liakhovetski , Tilman Schmidt , linux-serial@vger.kernel.org, Linux Kernel , Hansjoerg Lipp , Russell Doty Subject: Re: [PATCH] Add the ability to layer another driver over the serial driver References: <4533B8FB.5080108@mvista.com> <20061210201438.tilman@imap.cc> <457CB32A.2060804@mvista.com> <20061211102016.43e76da2@localhost.localdomain> <457D70A4.1000000@mvista.com> <20061211151943.2bbc720e@localhost.localdomain> In-Reply-To: <20061211151943.2bbc720e@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3031 Lines: 72 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 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/