In fact, if you are assuming that the board is a 8250-style UART,
serial.c should be relatively architecture independent. For example,
Linus only had to change 3 lines in order to allow serial.c to work on
the Alpha port. (Dec seems to have done something slightly different
with the OUT1/OUT2 lines, so how the Modem Control Register had to be
set was subtlely different.)
My original intention when I wrote the new tty layer interfaces was that
the tty driver layer --- i.e., console.c and serial.c would be hardware
specific. That is, that you would likely have to write a new serial.c
for a new hardware platform, since the serial port hardware would likely
be different. The fact that Linus could make only a few changes and
allow the EISA Alpha port to use the same serial card was actually a
surprise to me, although thinking more about it, it makes sense. After
all, it's the same bus architecture, and the same cards.... just a
different CPU, in essense.
It is true that when you take a look at some of the intelligent serial
board drivers, such as either the Cyclades or the Comtrol Rocketport
driver (which I wrote), and the dumb serial drive, there is indeed some
amount of code sharing that could potentially be done; however, it is
not clear to me that there is enough code sharing such that it's worth
trying to introduce yet another layer of abstraction here. (With the
efficiency hit that usually comes from adding the extra layer.)
- Ted