On Thu, Jul 12, 2007 at 02:19:47PM +0700, Darmawan Salihun wrote: > 1. 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. > 2. 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. > 3. 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 > 0xFF > > I 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 -- linuxbios mailing list [email protected] http://www.linuxbios.org/mailman/listinfo/linuxbios
