svn commit: r199827 - in head: include lib/libc/compat-43 sys/sys

[Dima Panov]

Author: kib
Date: Thu Nov 26 13:49:37 2009
New Revision: 199827
URL: http://svn.freebsd.org/changeset/base/199827
Implement sighold, sigignore, sigpause, sigrelse, sigset functions
from SUSv4 XSI. Note that the functions are obsoleted, and only
provided to ease porting from System V-like systems. Since sigpause
already exists in compat with different interface, XSI sigpause is
named xsi_sigpause.
Reviewed by: davidxu
MFC after: 3 weeks
head/include/signal.h
head/lib/libc/compat-43/Makefile.inc
head/lib/libc/compat-43/Symbol.map
head/lib/libc/compat-43/sigcompat.c
head/lib/libc/compat-43/sigpause.2
head/sys/sys/signal.h
head/sys/sys/signalvar.h

kib, you forgot about osversion bump, it is strongly needed.

This changeset caused jdk (may be not only jdk) breakage, as jdk-bsd-patches
always provide own implementations of sigingnore() for FreeBSD.

Patch for jdk16 port will be ready soon.

[Kostik Belousov]

Post by Dima Panov

Author: kib
Date: Thu Nov 26 13:49:37 2009
New Revision: 199827
URL: http://svn.freebsd.org/changeset/base/199827
Implement sighold, sigignore, sigpause, sigrelse, sigset functions
from SUSv4 XSI. Note that the functions are obsoleted, and only
provided to ease porting from System V-like systems. Since sigpause
already exists in compat with different interface, XSI sigpause is
named xsi_sigpause.
Reviewed by: davidxu
MFC after: 3 weeks
head/include/signal.h
head/lib/libc/compat-43/Makefile.inc
head/lib/libc/compat-43/Symbol.map
head/lib/libc/compat-43/sigcompat.c
head/lib/libc/compat-43/sigpause.2
head/sys/sys/signal.h
head/sys/sys/signalvar.h

kib, you forgot about osversion bump, it is strongly needed.

No. My interpretation of __FreeBSD_version is that the bump indicates
incompatible change in the interfaces. Sometime it is used to mark the
point where big changes hit the tree, possibly not related to interface
change.

Also, __FreeBSD_version denotes the kernel "version". We do support
running earlier usermode on the later kernels. Think about kernel-only
upgrades, compatXx libs and jails which can run arbitrary earlier
usermode. (The change in question is purely libc).

Said this, I think it is actually harmful practice to bump
__FreeBSD_version after API additions or feature implementation.

I can bump version for this case, but due to the above reason,
it would not make much sense.

Post by Dima Panov
This changeset caused jdk (may be not only jdk) breakage, as jdk-bsd-patches
always provide own implementations of sigingnore() for FreeBSD.
Patch for jdk16 port will be ready soon.

Ok, thanks for working on this.

[M. Warner Losh]

In message: <***@deviant.kiev.zoral.com.ua>
Kostik Belousov <***@gmail.com> writes:
: On Wed, Dec 02, 2009 at 07:25:56PM +1000, Dima Panov wrote:
: > On Thursday 26 November 2009 23:49:38 Konstantin Belousov wrote:
: > > Author: kib
: > > Date: Thu Nov 26 13:49:37 2009
: > > New Revision: 199827
: > > URL: http://svn.freebsd.org/changeset/base/199827
: > >
: > > Log:
: > > Implement sighold, sigignore, sigpause, sigrelse, sigset functions
: > > from SUSv4 XSI. Note that the functions are obsoleted, and only
: > > provided to ease porting from System V-like systems. Since sigpause
: > > already exists in compat with different interface, XSI sigpause is
: > > named xsi_sigpause.
: > >
: > > Reviewed by: davidxu
: > > MFC after: 3 weeks
: > >
: > > Modified:
: > > head/include/signal.h
: > > head/lib/libc/compat-43/Makefile.inc
: > > head/lib/libc/compat-43/Symbol.map
: > > head/lib/libc/compat-43/sigcompat.c
: > > head/lib/libc/compat-43/sigpause.2
: > > head/sys/sys/signal.h
: > > head/sys/sys/signalvar.h
: >
: > kib, you forgot about osversion bump, it is strongly needed.
: No. My interpretation of __FreeBSD_version is that the bump indicates
: incompatible change in the interfaces. Sometime it is used to mark the
: point where big changes hit the tree, possibly not related to interface
: change.
:
: Also, __FreeBSD_version denotes the kernel "version". We do support
: running earlier usermode on the later kernels. Think about kernel-only
: upgrades, compatXx libs and jails which can run arbitrary earlier
: usermode. (The change in question is purely libc).
:
: Said this, I think it is actually harmful practice to bump
: __FreeBSD_version after API additions or feature implementation.
:
: I can bump version for this case, but due to the above reason,
: it would not make much sense.

In the past, __FreeBSD_version has been used to expose changes in
interfaces (both plus, minus and delta) that are necessary for the
entire system. Adding an interface definitely qualifies because this
is a build-time issue, not a run time one.

Unfortunately, __FreeBSD_version has also been used to force kernel
recompiles lately since it is encoded in the kernel modules. Despite
this, it isn't just for kernels...

Warner

: > This changeset caused jdk (may be not only jdk) breakage, as jdk-bsd-patches
: > always provide own implementations of sigingnore() for FreeBSD.
: >
: > Patch for jdk16 port will be ready soon.
:
: Ok, thanks for working on this.

[Dag-Erling Smørgrav]

Post by Kostik Belousov
No. My interpretation of __FreeBSD_version is that the bump indicates
incompatible change in the interfaces.

...or the introduction of a new interface; see for instance r194210,
where simon@ bumped it to mark a new OpenSSL version with new features.
It is widely used in the ports tree to determine whether a particular
patch should be applied.

(actually, that's precisely the reason why __FreeBSD_version was
introduced, and it lived in userland for a while before eivind@ moved it
into the kernel in 1998)

Post by Kostik Belousov
Sometime it is used to mark the point where big changes hit the tree,
possibly not related to interface change.

Bumps are cheap, better one too many than one too few.

Post by Kostik Belousov
Also, __FreeBSD_version denotes the kernel "version".

No, it has been bumped for libc changes in the past.

DES