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.
Where can I get a copy of amiga_ser.c? It wasn't in your tar file...
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...
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
You misunderstand me. If you are assuming that everyone has a 8250, then
you shouldn't need an extra abstraction layer --- you should just be
able to change the inline functions for serial_out() and serial_in(),
which is the abstract interface to the registers on the 8250 UART.
There should very little changes that you need to make for a new
architecture. As I mentioned before, when Linus ported serial.c to the
Alpha, he had to add precisely two extra #ifdef's. Two extra #ifdef's
don't justify an entire new abstraction layer.
If, on the other hand, you want to allow the serial driver to share code
with non-8250 based serial driver --- such as the many intelligent
serial boards that are out there --- then the abstractions which you
are using aren't good enough to support these non-8250 UART serial
devices. And let me assure you, they most certainly exist.
Why don't I turn the question around. What's so different about the
access method to the 8250 UART's in the Amiga such that you need to
write a new layer, instead of just making minor modifications to
selected portions of the serial.c driver?
- Ted