Wolfgang Mauerer wrote:
> [moved to xenomai-core]
> Gilles Chanteperdrix wrote:
>> Wolfgang Mauerer wrote:
>>>> - gettimeofday should not have another timebase than
>>>> clock_gettime(CLOCK_REALTIME): in other word, the whole clock system
>>>> should be based on the ntp clock.
>>> Sorry, I'm not quite sure what you are talking about here. The NTP
>>> corrections are provided for the clock offered in the vsyscall page
>>> by Linux, so the clock is based on the NTP clock, isn't it? Or
>>> am I misparsing your statement?
>> Unless I misunderstood your patch, what you provide is:
>> gettimeofday which uses linux timebase
>> clock_gettime which uses Xenomai timebase unrelated to linux' timebase
>> This is unacceptable. What we want is a unique timebase.
> okay, I see your point now. But this sound more like 3.0 stuff, doesn't
> it? The goal right now is just to have some code that generates
> synchronised, NTP corrected timestamps on Linux and Xenomai, not
> to rework the base timer handling.
We are going to open a 2.6 branch soon (we are migrating Xenomai to a
new hoster, and this job is almost finished). This will go to 2.6. And I
am not going to merge anything that would provide two different
timebases for CLOCK_REALTIME. That is too unnatural. There are a bunch
of natural things which will not work with this approach. It create many
ways to shoot oneself in the foot. So the answer is definitely no.
>> vread is a function pointer call, which:
>> - requires vsyscalls, currently only implemented on x86 (and maybe ppc)
>> - is function pointer call, so damn slow on low end hardware.
> ... and fast as lightning on x86 when the call is made often, which
> is the important case when speed matters. So it makes sense on this
rdtsc is even faster. It is just one instruction.
The generic solution is even faster than the architecture specific one.
So, please implement the generic one.
>> On the one hand you make complicated code (which will be costly on low
>> end hardware) to avoid shutting interrupts around a few assignments, but
>> on the other hand you leave an architecture specific function pointer
>> call where we want a fast behaviour on average (remember, we do all this
>> to avoid a system call, which is only a few hundreds nanoseconds on your
>> big iron x86), and where we have a generic fast replacement. Sometimes,
>> I do not understand your logic.
> But using the same argument, you could get rid of Linux vsyscall based
> Would having the synchronised time stamp feature (maybe by another name
> than gettimeofday()) conditionally compiled on x86 be acceptable?
No. We have a generic implementation at hand for a limited amount of
additional effort. Let us do things properly.
Xenomai-core mailing list