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