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-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html