Serial driver abstraction...
Mon, 24 Jul 1995 14:10:45 -0400

--------- Received message begins Here ---------

> From tytso@MIT.EDU Mon Jul 24 11:48:01 1995
> To:
> Cc:,
> Address: 1 Amherst St., Cambridge, MA 02139
> Phone: (617) 253-8091
> Well,
> 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
> pc_serial.c.

Hi Ted, I'm glad you got in touch with me. All I know is that the Amiga and
Atari ports use this abstraction layer quite effectively and have been doing so
for some time. Take a look at amiga_ser.c (which is essential unchanged)
for an example of how easy it is to integrate.

As I mentioned before, *** we can no longer make the assumption that only
x86s will be using PC cards, be they PCI or ISA. *** This being said,
we should come up with an acceptable solution for everyone. There is a
tremendous amount of code sharing going on between any two archs using
a serial port. I don't see how you came up with the fact that there isn't.
If it's good enough for SCSI at multi-megabyte speeds, it should be good
enough for the serial port. Linux is already on it's way to getting and
integrated source tree, with machine dependent and independant parts.
This is a trend we cannot ignore, or we'll simple bloat the distribution
with duplicated source files. Anyways, we'll go through this same problem
again when the PPC/PCI machine come around.

As for the effciency hit, take a look at the code. You'll find exactly 1
extra memory indirection reference for the advantage of having arch
independant code. If you can measure the difference of that, I'd be suprised.

Anyways, I hear my code doesn't work yet anyways, (I don't have an x86 to test
it), so it's early at this stage. However, we should try to come up with an
agreeable solution. Do you have a proposal? I definitely think we need
a little more abstraction than serial.c currently offers, and at least some
of the defines I put in. (I actually saved 2 pages of memory by adding the
defines...) I do understand your position though. We should see what Linus &
the general linux community thinks before writing this off. If the consensus
is to leave it as is, so be it.

I think the assumption that everyone has at least an 8250 is valid. After
all, you made that same assumption when you wrote serial.c

What's everyones opinion?