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.
Looks like we found a troll to occupy this afternoon :-).
--
Gilles
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
