Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> Why? It delivers us the core mechanism we need for the rest as well -
>>>>> and it does not require fancy I-pipe hooks.
>>>> Because relying on the vdso/vsyscall only works on x86. Whereas
>>>> implementing clock slew down/acceleration at nucleus level and simply
>>>> sharing data between kernel and user through the the global sem heap,
>>>> works for all architectures.
>>> There are three kind of archs:
>>> - those that already support vgettimeofday & friends (x86, powerpc,
>>> maybe more)
>>> - those that do not yet though they could (I strongly suspect arm falls
>>> into this category as well)
>>> - those that never will (due to lacking user-readable time sources)
>>>
>>> We need temporary/permanent i-pipe workarounds for the last two, but I
>>> see no point in complicating the first category. This design aims at a
>>> longer term.
>> Well, I may be wrong, but I prefer generic code to arch-specific code.
>> Nucleus code to handle clock slow down/acceleration would be generic;
>> I-pipe code to signal NTP syscalls would be generic (and yes, even if
>> I-pipe patches are generated for all architectures, whether the code is
>> generic or specific makes a big difference);
>> User-space code to implement clock_gettime(CLOCK_REALTIME) using data
>> shared through the global sem heap would be generic.
>>
>> So, I think this design is future proof and easy to maintain. And I do
>> not see how it complicates x86 situation, since it is only made of
>> generic code.
>
> Well, OK, then place a small optional I-pipe hook into that part that
> normally writes the update into the vdso page (I think that is
> arch-specific anyway), replicating it into a specified page the nucleus
> may set up on a globally shared heap. That hook also has to maintain a
> seqlock like Linux does, ie. generating the same layout and semantics.
> It's just the transport mechanism, we can easily select it based on the
> arch's level of support.
>
> But I'm against any needless redirection through the nucleus (including
> potential nklocks etc.).
I do not really understand why you want to use the vdso page, since we
have the global sem heap anyway. clock_gettime already has a mean to
read a clock source and the frequency of this clock source, this is
guaranteed on all platforms, so I think the correction code can be made
generic.
However, duplicating the ntp related kernel code may be the real issue.
I have to look at that code to see how complex it is.
For the locking, well, if we have variables on a shared area to update
every time ntp corrects the clock, we will have problems doing it under
nklock anyway (the irq locking prevents from preemption on the local
cpu, but does not prevent the remote cpus running user-space programs
from accessing the shared area). So, we will have to devise some locking
mechanisms. But I do not see the reason for making this linux
compatible. If we keep the nucleus business separated, the nucleus
shared area will never have to be accessed by plain Linux, which will
access its area in the vdso, the Linux kernel doing its house keeping.
For the HPET clocksource, well, I do not share your enthusiasm, Linux
keeps complaining about the stability of the tsc of my laptop, though it
is a fairly recent core2 with the "constant_tsc" flag.
--
Gilles
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
