[LinuxBIOS] RFC Winflashrom Architecture -- Current Progress

[Darmawan Salihun]

Hi all,
    I want to report the progress that I made so far. Here they are:

1. The client (user mode) code is compilable with MinGW (currently
carried-out in Msys console).
    However, there are a few drawbacks:
    a. PCI accesses (libpci) is implemented using direct-I/O access
through the driver.
    b. Other variations of in/out  routine is also still direct-I/O
access through the driver.
    c. Memory mapping is already implemented. I'm still finishing the
limit of the physical memory ranges
       that should be "map-able" in the driver.
    d. The user mode code and the driver hasn't been integrated into one
executable file yet. Note that it used
        to be unified in a single executable file with the driver
integrated as a binary resource and loaded dynamically
        at runtime in my experimental code that was built with Microsoft
VC++.

2. There is a possibility to use _only_ MinGW to build all of the
components, including the driver.
    The driver can be built by using winpooch methodology:
     http://sourceforge.net/docman/?group_id=122629

OK. So that's the general overview for now.

Anyway, I want to ask a few details regarding the source code.
1.) Because there is _no_ reliable functions for sleep() and usleep()
that works seamlessly (portable with no logic differences)
     between the Windows version and the *NIX version. I'm using
myusec_delay() instead to replace those function
    to provide delay. Is that acceptable? or should I try using high
resolution timer in Windows NT/2K/XP instead?
    Note that Sleep() in Windows uses a different measure of time (in
milliseconds) compared to sleep() in *NIX (which is
   measured in seconds).

2.) Is there any "definitive" or "semi-definitive" I/O port address
ranges that I suppose to give an  R/W access? I mean, right now
     the 64K I/O space is  opened for access in the driver :-(. It
should be easy to limit the I/O port address range. However,
     I need to know those ranges.

OK. That's it. I plan to sign-off/submit the changes this week to
mailing list on saturday or sunday. Just for evaluation ;-).
It shouldn't be ack-ed because the driver is still troublesome as is the
libpci and some others.
Nonetheless, I need feedback on the real code. That's why I think it's
important to do that ASAP. It should've been last week.
But, I have some local issues here that I must take care :-(.

And some info: The mmap function in Unix is compatible with
memory-mapped file in Windows. Nonetheless, because there is no
                        such an analogy for /dev/mem in Windows. It's
useless to use the windows port of mmap() because it won't be able
                       to map the physical address range. Therefore, we
still need the driver that I've used for some time now.

Cheers,
Darmawan