I'm really late in this conversation, but just felt like adding
another proof of concept, as I am dealing directly with this on the
Sparc as we speak.
It was never my intention that serial.c would be separated into a
machine independent and machine dependent portion. While it is true
that it would be possible to factor out some amount of common coding in
serial.c and some of the other serial drivers into a "serial driver"
library which gets called from the machine independent code, I don't
believe that adding a new function table in the way that the Amiga folks
have done things is the right way to do things. Their attempt, IMNSMO, both
simultaneously did not go far enough --- they didn't make it general
enough to support intelligent serial boards --- and went too far in
other areas --- in some cases the amount of code that was saved wasn't
worth the extra layer of indirection that was required to save that tiny
bit of code.
When I wrote the serial driver on the Sparc, which consists of two
Zilog 8530 chips w/2-channels a piece, I started with the i386
serial.c driver. I was able to keep a surprising amount of code, what
I needed to directly rewrite was the initialization, the interrupt
routine, and the way configuration of the chip was changed.
Another point worth making is that the keyboard and mouse are run off
the second zilog chip, channel 0 being the keyboard and channel 1
being the mouse. Thus I found it necessary to place hooks in the
initialization and the interrupt code to satisfy this situation.
Also, on the Sparc one's console can be hanging off of one of the
channels on the first zilog chip (called /dev/ttya and /dev/ttyb in
SunOS land) and this provisions for this were also necessary. I
needed to place specialized hooks, no matter how small, in nearly
every function of the serial.c driver.
Point being, that I will say that the interface provided from the rest
of the tty code to my serial.c was just fine. And I feel that trying
to extract any amount of "common" code from serial.c and working from
there may not be the best of solutions, at least it would not help my
case at this point. I liked having control of everything that
serial.c does, it made things more efficient actually.
In the future, I will probably look to factor out some common code out
of serial.c, cyclades.c, and rocket.c --- in particular, the
dialup/dialin open() code, etc.
As noted above, some of the things dealing with open() may not be as
generic as you think. For instance, if the console is over the zs
serial line, and/or a kgdb debugging session has been started over
/dev/ttya and/or /dev/ttyb I need to check these things at open time
and punt the request if any of the above are true for the requested
serial line. Also, punts for direct opening of the keyboard/mouse
serial channels need to punted also.
Later,
David S. Miller
davem@caip.rutgers.edu