At 5:54 PM +0100 12/10/03, Christian Limpach wrote:
>Hello!
>
>There have been several times in the past that changes to the SA kernel part
>have also required changes to libpthread.  The result was that people who
>only updated one or the other did experience unexpected crashes.  I'd like
>to prevent this in the future.  On the next change which requires a
>simultaneous update of both kernel and libpthread, I'm going to add a
>version argument to the sa_register syscall.  Applications can then be
>terminated with an explicative error message instead of an unexpected crash.
>
>This is similar to the version checks we perform for LKMs.
>
>I don't feel that there is a need to burn more system call numbers for the
>SA syscalls because:
>- there hasn't been a formal NetBSD release since the SA syscalls were
>introduced.
>- the basic system does not need the SA syscalls to run.
>- we have made incompatible changes to the SA syscalls before.
>- the SA syscalls are not documented.

The exception is that application linked statically will suddenly fail.
Some vendors base their products on current so this will directly affect them.

>I feel this is preferable to using a different system call number each time
>if there are many occasions where this is necessary.  Using a different
>system call number would be preferable if we wanted to provide compatibility
>syscalls at the previous number.  Because the changes are often quite
>intrusive and extensive, this would quickly become unmaintainable.
>
>Looking at recent CVS log, a version number change would have occurred on
>2003/11/17 and 2003/09/16.
>
>I'll send another message when the version number is added or changed.

What about the future?  Will future changes cause application flag days?

-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.