[LinuxPPS] convergence patch

[Magnus Danielson]

Dear Hal,

>>> PS: What about the sys/timex.h (glibc) changes needed for nano? Does
>>> anybody know if they 'landed' with the maintainer?
>> I was just recalling this issue too. On the other hand one should maybe
>> ask the question if it is reasnoble that the linux-kernel and glibc
>> should require coordination like that. Wouldn't it be a better solution
>> to adjust the kernel timex.h such that glibc timex.h can wrap it with a
>> suitable #define such that copy-n-paste issues can be avoided?
>> This way would the actual definitions be in the linux kernel tree and
>> only conveyed thru to user-space programmers.
>> The glibc would then only need to supply the call wrappers and they
>> would require updates more rarely.
>>
>> Cheers,
>> Magnus
> 
> I opened a bug report with the glibc maintainers about the middle of last 
> year.  So they are aware of this but seem unable to figure out how to deal 
> with the issue.  The bug is still open so at least they have not decided that 
> it is invalid and I know that the maintainer has at least looked at in some 
> detail.  I do agree with Magnus that the current way this is setup is probably 
> a design flaw and this is probably why it is taking so long to resolve.  In 
> addition any fix has the potential to cause issues in existing user land 
> applications so they are being very careful about making any changes (after 
> this code has not be changed since kernel version 2.2).  

Their inability to track the kernel development on this interface is 
causing user-land applications (i.e. ntp with friends) not to work 
properly or make use of needed new features. The way they have done it 
they break the link between the running kernel and user-land 
applications which expect these new features.

For this interface, glibc (or any libc) is only to act as a call-wrapper 
over to kernel space, and not to act as an implementor of the core 
functionality. Thus, their concern should be to become as opaque to 
changes in underlying kernel as they can be while still providing the 
interface service.

The way the current interface is provided, it becomes a bug regardless 
if they keep or update to latest NTP version, as it will not mirror the 
kernel. The wrapping that I proposed would let the same glibc release 
provide the correct interface regardless of which variant the current 
kernel provides.

Thus, the current way it is implemented is a big bug, and just provide 
the diffs to the latest kernels variant of the timex.h will not solve 
that bug, just hide the problem for users of the new kernel but create a 
problem for new users.

The trouble is that I don't think the current kernel version of timex.h 
is easily setup to be compiled in a user-space world. Unfortunately it 
needs to be modified as well, unless someone can point me into the 
correct direction, such that it can be compiled in the user-space context.

So, basically, we are screwed either way. The best way we can help is to 
provide the diffs to the kernel such that __LIBC or something tags the 
headers into a user-space compilation compliant mode and after that help 
glibc towards that direction.

> The other thing is that as far as I can determine the only user land app that 
> uses this API is ntp so perhaps the best solution is to modify the ntp build 
> so that it no longer uses glibc and instead builds against the kernel 
> directly.

I have tried that. Unfortunatly the kernel header seems to depend on too 
many things that makes them kernel-space only compliant.

I would think there are some few additional apps, but they are in any 
case fairly NTP-aware and we know them fairly well anyway. I agree that 
it should not be a huge problem to keep them up to date.

Cheers,
Magnus