On 7/25/07, Stefan Reinauer <stepan@coresystems.de> wrote:

* Darmawan Salihun <darmawan.salihun@gmail.com> [070724 06:11]:
> I'm currently completing the MMIO mapping routine
> in the device driver, but I have a problem as follows:
> - The current driver doesn't limit the application
>   to map certain MMIO phy address range even if it's
>   already mapped by another routine in the same
>   application. I actually plan to "lock" the mapped
>   MMIO phy address range so that once it's mapped, it
>   must be unmapped first before another routine can map
>   that range. Actually, this is to avoid two routine
>   from manipulating the same area at the same time.
>
>   My question is, do you think we really need the "lock-ing"
>   mechanism in the driver? I just think it is a potential
>   problem if the MMIO access is not "lock-ed".

Since the places where mmap happens are only a few I'd say it is not
really "needed". It's a good idea though as it is a safety measure
against application bugs.

The MMIO mapping routine completed. I need more testing though.

Anyway, after evaluating all of the possible development path last week,
I came to conclusion that the robustness of winflashrom code and its evolution
in to the future will be guaranteed if the architecture is as follows:
1. PCI detection routine in Windows is in "user mode" and parsing the data from Windows device "database".
2. The driver will contain the chipset_enable and board_enable routine as they are doing direct IO transactions which should be hidden from the user mode application as much as possible to mitigate possible exploit in the future. It will ease migration into WDK (ofr Windows Vista support in the future) as well.
3. As before, user mode application part of winflashrom will be compiled with MinGW and its driver will be compiled with Microsoft's native device driver compiler that comes with their driver development kit. I decided that this is the best approach because it will be problematic when we migrate to Windows Vista and take a different route.

Anyway, the architecture above will make the winflashrom significantly differ from flashrom.
However, "unification" with the flashrom base code is not impossible but I think it's better to do it gradually. Peter's idea of using a "simple protocol" to exchange data between the application and the driver for the chipset_enable and board_enable routine sounds solid at the moment. I will implement it for the rest of Google Summer of Code coding phase and I think we will have a working code in about two weeks from now. However, I'm still looking for other ideas in this matter.

Regards,

-- Darmawan Salihun a.k.a Pinczakko
--------------------------------------------------------------------
-= Human knowledge belongs to the world =-