In message 20030707152907.GA2816@buici.com you wrote:
cpu/arm920t/s3c24x0/ cpu/arm920t/other_1/ cpu/arm920t/other_2/ ...
What do you think?
OK. Does this mean that the configuration line in Makefile says:
... arm arm920t/<subcpu> <boardname>
Probably not. Maybe we can solve this by a #define in the board config file.
There should be no _board_-specific drivers in CPU directories. We had this discussion before, and all such cases that I'm aware of are really _processor_-specific drivers.
Perhaps I am misspeaking. These serial drivers are chip specific. ARM920T, however, is *not* a chip. The serial driver in the ARM920T directory is specific to the Samsung implementation.
Understood, and agreed. Should be cleaned up once we implement such a change.
- Drivers, such as serial, could be made to export a function table. This would allow driver selection by choosing which file to compile and link.
Isn't this how it works right now?
The serial driver for the samsung chip exports serial_getc(void) and like routines. It could export more generic routines using a jump table. I think this is the same thing that happened with the x86 port.
Which advantage do we get from an additional level of indirection when the functions are known (getc, tstc, putc, puts) anyway? IMHO it just adds additional complexity (needs manual relocation) and wastes memory.
Best regards,
Wolfgang Denk