[LinuxBIOS] Winflashrom -- Current Status

[Darmawan Salihun]

Stefan Reinauer wrote:
> * Darmawan Salihun <darmawan.salihun at 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