Date:	Tue, 19 Dec 2006 13:27:33 -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

This is a continuation of a previous discussion.  There are
serial interfaces to IPMI chips that I need to support and
I need a way to access these at panic time or when the
system is in a state where it can't schedule.

I have written a layered driver for the serial core, but Alan
says that a line discipline is the right way to have a driver
access a serial port.  That seems rather unnatural to me
(none of the other layered drivers do this), but it's not the
end of the world, and the serial driver is "special" in some
regards.

Alan and I discussed this some and he suggested I look at a
way to unify all the various "raw" users of serial ports, things
like kgdb, serial console, and the IPMI driver.  That sounded
like a good idea at the time, so I've been working on that.

Unfortunately, it hasn't turned out so well.  A line discipline
won't work for kgdb or consoles; the driver needs some
mechanism to register the serial port so kgdb can find it.
Consoles need some special registration, too.

This is what I would like to propose:  Keep the concept of
a layered driver like I have already done, but modify the
code so the uart can register very early, in time for kgdb
and consoles.  Add a uart poll routine, poll setup and
poll quit routine, and a few other things needed by
consoles.  kgdb can use this, and the serial_core code
can use it to do a console.

This would eliminate most of the console code from the
individual drivers.  The normal write buffering could be
used by the serial console (though it would have to
insert its own info structure when it did a console write).
The console also needs routines to get the default values
for systems that get defaults through things like open
firmware.  And maybe a routine for polling CTS.

The poll routines could be propagated up to the tty
layer fairly easily, if required, for use by other drivers.
I really don't like having to have two mechanisms for
a driver to do a write, one normal and one when the
system can't schedule.  And a poll routine reduces
code duplication, the driver works with all the normal
routines.  No special read or write operations.

Anyway, this is what I think works best for all parties.
I'll continue down this path for now.

Thanks,

-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