Stefan Reinauer wrote:
- Darmawan Salihun darmawan.salihun@gmail.com [070714 05:13]:
Application logic belongs into the application, not into the driver.
This makes me wonder if the current driver is good enough :-/
Take it as a suggestion. If there is no good way of doing it different, than the way you are doing it in your driver is fine.
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 ?
good question. There is certainly an advantage to both approaches.
Having a simple driver would allow to update the userspace program while the driver always stays the same.
Nonetheless, this would require driver recompilation every time we have new board support. It won't be a big problem once everything can be handled by MinGW alone (by means of Winpooch -- http://sourceforge.net/docman/?group_id=122629). Anyway, I haven't finish moving board_enable.c and chipset_enable.c to the driver.
On the other hand, letting userspace do arbitrary io accesses is not good.
Can anyone else except flashrom easily use the driver? By accident? On purpose, to break into the system?
I don't think it's easy to use flashrom driver by accident because it's loaded and unloaded dynamically. It only runs when flashrom is executing. However, I think it's best to keep the direct I/O routine in the driver and application will exchange data through the so-called IRP (I/O request packet) with the driver. Currently, IRP is in use but not efficient because sometimes it's only exchanging one or two bytes for I/O accesses. It's not efficient if we take into account that we can move almost the entire I/O accesses to the driver and do it there.
Anyway, there's an issue regarding the PCI library that I'm aware just recently. Which one is the following approach is better? 1. Let windows detect the PCI devices in the system and just parse the data that it presents.
or
2. Detect the PCI devices in the system ourself by doing direct I/O (PCI detection) in the driver. This way, the code will detect the device using libpci that's ported to kernel mode driver.
That's all for now. More to come ;-).
Regards, Darmawan Salihun