On Fri, 1 Jun 2007, Jan Rekorajski wrote: > > I am looking into a solution that would make it automatic without the > > need of involving userland which just does not seem right here -- you do > > want to run your kernel with "init=/bin/bash" or suchlike and have your > > virtual terminal console usable. I will remove the old lk201 bits then. > > Why not do that in the driver? AFAIK there can't be anything else on > those ports. Well, with some soldering skills you can make an adapter that will convert each of them to an ordinary 3-wire serial line. Therefore I think the best approach would be only doing the binding of the keyboard and the mouse port to the input subsystem if the virtual terminal device is opened. This is unfortunately not the way how things are set up right now. Opening the VT does not trigger a query for the associated input devices that could pull the necessary drivers. It merely uses whatever got registered beforehand (or actually at any point) and for the DECstation it means dummy devices (how useful!). But that is not the most important reason. That in fact is the way how it could be implemented in the driver. It means at least hacks to the receive interrupt and another hack to implement an alternative transmit interrupt handler. I refuse to do polled transmission with this chip because of its performance hit, sorry, and with the dz driver, which requires a corresponding change, the hit would be even worse. Finally, the lone reason for introducing the serial subsystem was to abstract serial ports from the TTY layer, so any sort of devices could use them, regardless of whether they resemble a terminal or not. And there is a proper serio driver for this abstract serial port already implemented. Therefore introducing hacks to the serial driver "under the bonnet" is certainly not the way to go. We did have such hacks in 2.4, but that was because there was no generic serial port layer back then and all serial ports were TTYs. ;-) Besides, I think the driver should not enforce any policy, because it does not "know" or enforce the external wiring of the serial ports. These are the part of the platform (and please note that there are two variations available for the DECstation and other two for the DEC 3000 AXP) and it's the platform that should mark each port appropriately. I do admit at the moment the device handled by the driver is not handled as a platform device as it should, but I'd like to avoid short-term hacks that do not add value. The DECstation port needs a generic way of registering platform devices (all the bits on the motherboard that do not pretend to be TURBOchannel options) like some other platforms already do and when this is implemented the serial ports will be handled as necessary as a part of it. Maciej
