Re: git: e2650af157bc - main - Make CPU_SET macros compliant with other implementations

On Thu, Dec 30, 2021 at 11:54 AM Stefan Eßer <se@freebsd.org> wrote:
>
> The branch main has been updated by se:
>
> URL: https://cgit.FreeBSD.org/src/commit/?id=e2650af157bc7489deaf2c9054995f0f88a6e5da
>
> commit e2650af157bc7489deaf2c9054995f0f88a6e5da
> Author:     Stefan Eßer <se@FreeBSD.org>
> AuthorDate: 2021-12-30 11:20:32 +0000
> Commit:     Stefan Eßer <se@FreeBSD.org>
> CommitDate: 2021-12-30 11:20:32 +0000
>
>     Make CPU_SET macros compliant with other implementations
>
>     The introduction of <sched.h> improved compatibility with some 3rd
>     party software, but caused the configure scripts of some ports to
>     assume that they were run in a GLIBC compatible environment.
>
>     Parts of sched.h were made conditional on -D_WITH_CPU_SET_T being
>     added to ports, but there still were compatibility issues due to
>     invalid assumptions made in autoconfigure scripts.
>
>     The differences between the FreeBSD version of macros like CPU_AND,
>     CPU_OR, etc. and the GLIBC versions was in the number of arguments:
>     FreeBSD used a 2-address scheme (one source argument is also used as
>     the destination of the operation), while GLIBC uses a 3-adderess
>     scheme (2 source operands and a separately passed destination).
>
>     The GLIBC scheme provides a super-set of the functionality of the
>     FreeBSD macros, since it does not prevent passing the same variable
>     as source and destination arguments. In code that wanted to preserve
>     both source arguments, the FreeBSD macros required a temporary copy of
>     one of the source arguments.
>
>     This patch set allows to unconditionally provide functions and macros
>     expected by 3rd party software written for GLIBC based systems, but
>     breaks builds of externally maintained sources that use any of the
>     following macros: CPU_AND, CPU_ANDNOT, CPU_OR, CPU_XOR.
>
>     One contributed driver (contrib/ofed/libmlx5) has been patched to
>     support both the old and the new CPU_OR signatures. If this commit
>     is merged to -STABLE, the version test will have to be extended to
>     cover more ranges.
>
>     Ports that have added -D_WITH_CPU_SET_T to build on -CURRENT do
>     no longer require that option.
>
>     The FreeBSD version has been bumped to 1400046 to reflect this
>     incompatible change.
>
>     Reviewed by:    kib
>     MFC after:      2 weeks
>     Relnotes:       yes
>     Differential Revision:  https://reviews.freebsd.org/D33451

Hi,

This breaks a lot of ports,  like  lang/python38.
Could these kinds of changes on public headers be tested with an
exp-run,  and reverted in the mean-time?

Antoine