Subject: Re: SA/pthread syscall versioning
To: Christian Limpach <email@example.com>
From: Matt Thomas <firstname.lastname@example.org>
Date: 12/10/2003 09:14:33
At 5:54 PM +0100 12/10/03, Christian Limpach wrote:
>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
>- 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: email@example.com
3am Software Foundry www: http://3am-software.com/bio/matt/
Cupertino, CA disclaimer: I avow all knowledge of this message.