Where can we find the benchmark package?

Theodore Ts'o (tytso@mit.edu)
Mon, 24 Jul 1995 11:47:29 -0400

having looked at the breakdown of your modified serial driver,
I'm not terribly happy with the breakdown of the abstraction. The
bottom line is are you assuming that the architecture-independant
portion of the serial driver will be driving a 8250-style UART or not?
If you are not assuming this, there is still too much hardware-dependent
code in the serial.c; if you are assuming that the board you will be
driving really is a 8250-style UART, then there's way too much stuff in

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