Darmawan Salihun wrote: > 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). > I forgot to say that it's possible to use high resolution timer from Windows API instead.
> 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 > > > > > -- linuxbios mailing list [email protected] http://www.linuxbios.org/mailman/listinfo/linuxbios
