On 02.12.2009, at 23:20, Gilles Chanteperdrix <gilles.chanteperd...@xenomai.org
> Wolfgang Mauerer wrote:
>> Gilles Chanteperdrix wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> I surely don't want to duplicate ntp code, just the results it
>>>>> spits out
>>>>> (e.g. into the vdso page).
>>>> Ok, good point, we can avoid duplicating ntp code, but the vdso
>>>> trick only works on two architectures. So, IMO, the nucleus
>>>> should get
>>>> the infos, and copies them to the shared area. The question is to
>>>> if the infos are portable/in usable units such as nanoseconds or
>>>> source ticks.
>>> Ok. Had a look, the info is pretty much generic. We can use it on
>>> architectures. The point which would generate the I-pipe event is
>> completely agreed. But this required arch-specific changes to the
>> I-pipe patch and cannot be done in a generic fashion.
> Well, it can be done in many ways. One of them is to create a function
> static inline ipipe_vsyscall_update(whatever)
> in linux/clocksource.h
> and replace calls to vsyscall_update in generic code with a call to
> So, no, this does not necessarily requires arch-specific changes.
> However, changing it in the arch-specific way is probably the easier
> maintain on the long run (if we use the method just sketched, we will
> have to check with every release if a new call to vsyscall_update
> appears). Besides, for the architectures which do not implement
> vsyscall_update (the majority, xenomai-wise, only x86 and ppc
> vsyscall_update), the call to ipipe_dispatch_event may be put in the
> empty implementation which may be found in linux/clocksource.h.
>>>>> The kernel need to synchronize with user land, so the problem is
>>>>> (almost) the same as with obtaining the original data from Linux
>>>>> directly: user land can only use a retry or a smart fall-back
>>>>> to obtain consistent data.
>>>> Well, ok, I imagine something like a revision counter. But I do
>>>> not see
>>>> how it would work on an SMP system (kernel writing on one CPU,
>>>> user-space reading on another cpu).
>>> Ok, I had a look at seqlock.h, we can do it the same way, in an
>>> area of
>>> the global heap. We will have to provide our own implementation
>>> since we
>>> can not include linux/seqlock.h in user-space. update_vsyscall on
>>> turns off the irqs, to protect against the same code or some reader
>>> being called in an interrupt handler. We will have to do the same.
>> But then the code can loop potentially unbounded, can't it? It may be
>> that I'm missing something, but this was the initial reasaon for the
>> three-buffer idea I've presented initially.
> Well, on a normally running system, the update takes place for every
> Linux timer interrupt (or is it only for the periodic tick ?), anyway,
> if real-time code is running, there is no chance that it can be
> preempted by a Linux timer interrupt, and if the code is called from
> real-time context, we do not care much.
For a tickless System, it's only the periodic Tick, Not every Timer
> Note that we already use such code for tsc emulation on some
> and well, it works. And this is normal, the chances to get preempted
> several times in a row by a timer interrupt without being able to
> complete the loop are pretty low. Otherwise it would mean that there
> plenty of timer interrupts.
So that means, in essence, that you would accept probabilistic
algorithms in realtime context?
Xenomai-core mailing list