I'm in the process of writing a new device driver for UART devices (ala 16550). I wanted to discuss what I'm doing, and offer an opportunity to comment:
1) I'm writing a "common framework" so that pretty much all 16550-work-alikes could use the common code. This would allow pcser, asy.c and my new multiport support to all be consolidated. I'm lifting large portions of asy.c in the process, but I'm gutting some parts of it. (It is probably also useful to cardbus serial ports and a variety of modem devices as well...) 2) The main reason for this is to support CyberSerial (SIIG) multiport serial devices. I have an Ultra 20, and was very dismayed when it didn't have a serial port. Furthermore, I couldn't find an inexpensive USB serial device that was usable either! 3) Am I insane? Should just try to "hack" support into asy.c rather than creating a new class? I don't know . But there seems to be a number of serial port drivers out there with most of the same functionality. 4) I am not planning on supporting non-16550A workalikes. More on that in moment, but notably, I don't want to support weird chips or intelligent IO, or anything like that. Just plain old UART. 5) Note that I said _16550A_ (_A_) . I am thinking that there is little to no benefit in trying to continue to support fifoless 16450s or original (broken fifo) 16550s. I'm hoping that those devices are not of interest for Solaris any longer (Solaris 10 calls for a 120 MHz class Pentium in its system requirements). I figure that pretty much any on-board UARTS are going to be 16550As or better, and any add-in cards are easily replaced with "working" (useful) devices. Is this policy insane? Are there folks out there who want to run Solaris 10/11/OpenSolaris on these ancient serial ports (or modems that emulate fifoless 16450s)? I hope not! If you have contrary evidence, please let me know! 6) As a consequence of this, it should be nearly trivial to rewrite pcser using purely Open Source code, so that we can replace the closed-source version that is in OpenSolaris right now. 7) I'll be supporting any baud rates that the device can do without "unusual" programming. (I.e. I'm not going to be making use of, at least not initially, the more flexible clock programming available on 16950s to get to the really high data rates. I only have one cyberserial card, and none of my normal hardware talks higher than 115.2K.) 8) Nor am I going to be making use of (initially) the other advanced features like 9-bit data streams, "automatic" flow control, etc. For the most part I'll just use the ordinary 16550A features, plus larger FIFOs. The rationale here is that unless I want to abandon older 16550As, I have to at least support the old way, and so there isn't much additional benefit of supporting _both_ ways. In the 9-bit data case, I just can't easily test it, since I don't have any 9-bit hardware to play with. (To say nothing of the problem of figuring out how to expose a 9-bit data stream into user application code.) I guess that once I have it all working at some useful level, I'll want to commit this to a new community, so that folks can start to play with it. If you have any interest in this, please let me know. Please let me know if you have any other thoughts about this. -- Garrett D'Amore, Principal Software Engineer Tadpole Computer / Computing Technologies Division, General Dynamics C4 Systems http://www.tadpolecomputer.com/ Phone: 951 325-2134 Fax: 951 325-2191 _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
