[Rpcemu] CMOS clock in Linux - issue RPCI003

Kees Grinwis kees at grinwis.org
Wed Dec 10 15:11:15 EST 2008

Hello Everybody,

I'm currently working on the implementation of the real time clock
emulation in the Linux version of RPCEmu and although the changes
required are pretty straightforward, there are some (other) issues
that I want to tackle at the same time. These issues are mainly
related to the way platform specific code is marked in the RPCEmu

I suggest to have a look at the attached source of a simple test
application related to the implementation of the retrieval of the
current time from the operating system before continuing reading this

As you might have noticed, I've introduced some defines at the top of
the file and use these later in the "cmosgetsystemtime" function:
> #if defined linux || defined __linux
>     #define RPCEMU_UNIX
>     #define RPCEMU_LINUX
> #endif
> #if defined WIN32 || defined _WIN32
>    #define RPCEMU_WIN32
> #endif

It is my intention to make these defines global, either by adding them
to the compiler-flags or by separating them to a dedicated header
file. I prefer the first solution, so that we don't have to include
the "defines header file" each time we need it. (Although I've
realised, just before sending this mail that there is a charm to the
solution with the "defines header file", when using the file based
solution the identification of files containing platform specific code
has become somewhat easier...)

However I'm unsure what the impact of that solution would be on the
Win32 version of RPCEmu. Is the compiler used for the Win32 version
also capable of adding one (or more) defines from the command line?

Apart from the change related to the way platform specific code is
handled, there is also the issue related to a high precision time
function. I'm currently using the normal C time function to read the
current time, however the internal clock is more precise than that.
Should the retrieval function updated to use a more (Linux specific)
precise timer, or is the current solution adequate?

Kees Grinwis

More information about the Rpcemu mailing list