[LinuxPPS] convergence patch

[Magnus Danielson]

Udo van den Heuvel skrev:
> Magnus Danielson wrote:
>>> 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.
> 
> Interesting idea. I think it needs to be discussed in a broader context 
> like linux-kernel and perhaps a place where also glibc guru's hide.
> 
> Wouldn't this proposal cause issues between userland and kernel? (when 
> either one changes)

Well yes... the trouble is here that we want updates made in the kernel 
space to be available to updated user space application(s) but we are 
currently limited by the upgrade of the glibc too, even if glibc is not 
a true implementer of the interface. If they where, it would be their 
concern.

The interface is versioned, but unfortunatly this is done not by a call 
but through a header defined constant, so dynamic version handling is 
not available. Changing the interface to a dynamic version interrogation 
would be possible if one place some trick with how the #define is 
written, but then care must be take to ensure that it makes a call to 
the kernel to ask the kernel on the version of the interface it provides 
rather than have glibc return the version.

However, if we look at this particular interface we can conclude that 
the rate of change in this interface is not significant. glibc just 
sampled it in the previous version. The trouble is that in Linux, it's 
the glibc sources and not the kernel sources that holds the headerfile 
which is relevant. This is the mistake which other OSes have avoided and 
rapid upgrade and ensuring kernel and user space to be coordinated has 
not become an issue. If you read the ntp sources you will discover that 
it uses the version of the interface and adapts itself accordingly. In 
reality, from other OSes, maintaining the kernel and the application in 
sync on the interface side is not too problematic. We have the 
unfortunate situation that glibc publish the header file the application 
see, and the kernels header-file is not usable as a replacement as it 
seems to be compilable in user-space. This solution prohibits the use of 
new kernel features from user-space, not because they are not 
coordinate, but since the glibc is not coordinated.

This is a created obstacle which creates a more complex coordination and 
upgrade effort with no obvious gain to the user land applications, at 
least not for this particular case. I thus propose to remove the 
obstruction rather than only upgrade it. This interface was designed to 
provide a kernel/user interface and it was designed to work in the same 
way over multiple OSes and it uses versioning so that the userspace can 
adapt to the capabilities of the kernel, as flaged through the header 
file. Please notice how the timex.h is burried way down in glibc 
linux-specific stuff. This is a linux issue, not a generic glibc issue.

Cheers,
Magnus