On Thu, Jul 12, 2007 at 02:19:47PM +0700, Darmawan Salihun wrote:
- Libpci abstraction for Windows. In this case the libpci logic in
the flashrom code base need not be changed. I will make a "libpci for Windows" that doesn't change the logic within the current flashrom code. Even after the redesign, we might choose to preserve this part.
Perhaps you can make a small libpci-win32 package out of it? I'm sure others would appreciate it as well.
- Direct I/O access abstraction. I think, in the short term, I
will just provide a simple direct I/O "compatibility layer" for inX,outX family of functions in the winflashrom.
This can just be some #defines, use some functions in Windows and the normal in()/out() stuff otherwise.
Put this in some header:
#ifndef __WIN32__ #define my_inb(a,b) inb(a,b) #define my_inw(a,b) inw(a,b) #define my_inl(a,b) inl(a,b) #endif /* __WIN32__ */
..and then implement my_in[bwl]() in a .c file together with all the other stuff needed for Windows. Have a conditional in the Makefile to build and link that file on Windows only. Voila, done.
- File I/O abstraction. We might need this because fopen(..)
behaves not exactly the same in Windows and *NIX.
C89 has the b mode so just change all fopen calls to use "rb", "wb", "ab", "rb+", "wb+" and "ab+" respectively.
do you think it's good to make a branch for the current flashrom code in order to develop the unified (redesigned) flashrom that will host a single code base for both the *NIX version and winflashrom?
Is that really needed? Just submit nice and neat patches against trunk to get them reviewed, acked and applied.
Another note that I have difficulty in limiting the direct I/O access in the current driver because I don't know exactly which port to give access to and which one to block. Below is what I've found from the current flashrom code so far. I/O port usage:
0x2E (Winbond W836_INDEX port) 0x2F (Winbond W836_DATA port) 0x4E 0x4F 0xCD6 0xCD7 0xCFC - 0xCFF (PCI I/O port on x86) 0xC6F a "base + 0x4D" in Via Epia motherboard 0xE1 0xE800 (what port is this? ) 0xE801 0xE802 0xE803 0xE804 0xE807 0xEB 0xFFI couldn't conclude the the I/O port ranges to open from the port list above because there is still unknown (I think it's dynamically relocatable) I/O port such as the one used by EPIA board. Any explanation on this issue?
This list is still much better than allowing everything!
As for the EPIA board, well, where is that base specified? In a PCI config register or where?
//Peter