Stefan Reinauer wrote:
- Peter Stuge peter@stuge.se [070712 17:27]:
Then compile board_enable.c also into the app, but not to call any of the functions (which would fail anyway) but only to get the same board_pciid_enables list. The struct may have to be extended to have a unique index for each entry so that the driver and app can agree on which function is which.
All of the device detection should be done where it is easiest to do it. Since the driver will need to do safe PCI accesses for board enables perhaps it makes sense to contain all PCI accesses in the driver.
On the other hand, perhaps the app will need to do some PCI accesses to choose the right board_enable function and then it's better to do most of them in the app.
What do you think?
Application logic belongs into the application, not into the driver.
This makes me wonder if the current driver is good enough :-/
Another general matter, make sure the app and driver can exchange version numbers. That way both the driver and the app could have compatiblity code in order to be backwards compatible.
The driver should be stupid enough so it does not need to be changed. There is no need for a driver in Linux, either, it's merely a makeshift.
The reality is the current driver is as stupid as it is. Because, it responds to every direct I/O functions (inb, outb, etc.) in the correct manner and mapped the requested physical address range as we expect from mmap'ing /dev/mem.
However, I'm thinking and experimenting about moving the board_enable and chipset_enable support to the driver, so that every low-level accesses is kept to the driver.
Which implementation approach do you think is best ?
Honestly, looking at the current "design paradigm" that I can read from flashrom, the simplistic approach is the one that fits the original flashrom. But, I left the decision to all of us here.
-Darmawan Salihun