Hence, serial.c is the 8250/16450/16550A UART driver (which works on
both the ALPHA and the 386/486/586 platforms). The cyclades.c file is
the Cyclades intelligent serial board driver. The Comtrol Rocketport
driver (which I wrote on contract to Comtrol, Inc.) is distributed as a
separate loadable module, but like all of the other drivers it doesn't
have any dependencies on serial.c. The same is true for the Digiboard
intelligent board, as well as the Stallion intelligent serial board, and
many other serial drivers.
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.
Hence, I believe things can definitely stay the way they are. In the
worse case, people can write a 680x0-only driver, as Albert Cahalan
suggested, as well as a Mac specific driver, and a PPC specific driver.
(Although if any of these systems are really using a true National
Semiconductor UART compatible board, they should be able to use the
mainline serial.c with very little changes --- for example, it only
required changing three lines to support the ALPHA.)
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. Alternatively, I may look to move some
of this code into the high-level tty layer. Either or both will help
simplify the task of writing new tty drivers. However, I feel quite
strongly that struct tty_driver should point to a hardware specific
layer, and that inserting yet another layer below this one is the wrong
way to go. That way lies STREAMS, inefficiency, and madness. :-)
- Ted