In article <a0602048dbbfd388ccbec@[192.168.1.24]>,
Matt Thomas <matt@3am-software.com> wrote:
>At 1:46 PM -0500 12/10/03, Allen Briggs wrote:
>>On Wed, Dec 10, 2003 at 07:33:56PM +0100, Christian Limpach wrote:
>>>  I don't want to specifically argue against compatibility code, I primarily
>>>  want to argue for a sane way to prevent the lack of compatibility code from
>>>  causing an unexplainable crash.
>>
>>I think it's a good idea to version the interface.  If the interface
>>is versioned, then it's at least possible to have compatibility
>>code in place or to, as Christian seems to be after, at least detect
>>a probable incompatibility.  It seems to be a definite improvement
>>over the current situation.
>
>I agree versioning is needed.  I'm just wondering about its future
>implications.  Once 2.0 is released, its SA syscall interface will need to be
>supported by future COMPAT_xxx code if the SA syscall interface is ever
>incompatibly modified or enhanced.

Yes, once 2.0 is released. Before then it is adequate to require libpthread
and kernel to be in sync, and a recompilation for static binaries.

>Maybe some care should taken now to make sure the new SA syscall interface
>will not need such a future flag day.
>
>Also, I'd like to see a description comparing the current SA syscall
>interface to the new improved one.  There may be ways of supporting
>the old programs that aren't much work.  Anyways, those syscalls
>should be documented.

I will let Christian describe the differences.

christos