public inbox for newlib-cvs@sourceware.org
help / color / mirror / Atom feed
From: Sebastian Huber <sh@sourceware.org>
To: newlib-cvs@sourceware.org
Subject: [newlib-cygwin] Make CPU_SET macros compliant with other implementations
Date: Fri, 24 Jun 2022 05:43:44 +0000 (GMT)	[thread overview]
Message-ID: <20220624054344.D58053850235@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=e927f541f7b6b238fcfe009caa0b156a1588566d

commit e927f541f7b6b238fcfe009caa0b156a1588566d
Author: Stefan Eßer <se@FreeBSD.org>
Date:   Thu Dec 30 12:20:32 2021 +0100

    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

Diff:
---
 newlib/libc/sys/rtems/cpusetalloc.c         | 2 +-
 newlib/libc/sys/rtems/include/sys/_cpuset.h | 9 ++++++++-
 newlib/libc/sys/rtems/include/sys/bitset.h  | 8 +++++---
 newlib/libc/sys/rtems/include/sys/cpuset.h  | 6 +-----
 4 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/newlib/libc/sys/rtems/cpusetalloc.c b/newlib/libc/sys/rtems/cpusetalloc.c
index e2b198505..5388dd0a4 100644
--- a/newlib/libc/sys/rtems/cpusetalloc.c
+++ b/newlib/libc/sys/rtems/cpusetalloc.c
@@ -32,7 +32,7 @@
 #include <sys/cpuset.h>
 #include <stdlib.h>
 
-cpu_set_t *__cpuset_alloc(int num_cpus)
+cpu_set_t *__cpuset_alloc(size_t num_cpus)
 {
   return (cpu_set_t *)malloc(CPU_ALLOC_SIZE(num_cpus));
 }
diff --git a/newlib/libc/sys/rtems/include/sys/_cpuset.h b/newlib/libc/sys/rtems/include/sys/_cpuset.h
index c6383f363..f27bfcc03 100644
--- a/newlib/libc/sys/rtems/include/sys/_cpuset.h
+++ b/newlib/libc/sys/rtems/include/sys/_cpuset.h
@@ -1,4 +1,4 @@
-/*-
+#/*-
  * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
  *
  * Copyright (c) 2008,	Jeffrey Roberson <jeff@freebsd.org>
@@ -49,4 +49,11 @@
 __BITSET_DEFINE(_cpuset, CPU_SETSIZE);
 typedef struct _cpuset cpuset_t;
 
+#ifndef _KERNEL
+__BEGIN_DECLS
+cpuset_t *__cpuset_alloc(size_t set_size);
+void __cpuset_free(cpuset_t *ptr);
+__END_DECLS
+#endif
+
 #endif /* !_SYS__CPUSET_H_ */
diff --git a/newlib/libc/sys/rtems/include/sys/bitset.h b/newlib/libc/sys/rtems/include/sys/bitset.h
index c9448a73a..5ff6beeb8 100644
--- a/newlib/libc/sys/rtems/include/sys/bitset.h
+++ b/newlib/libc/sys/rtems/include/sys/bitset.h
@@ -315,8 +315,6 @@
 /*
  * Dynamically allocate a bitset.
  */
-#define __BITSET_ALLOC(_s, mt, mf) malloc(__BITSET_SIZE((_s)), mt, (mf))
-
 #define	BIT_AND(_s, d, s)			__BIT_AND(_s, d, s)
 #define	BIT_AND2(_s, d, s1, s2)			__BIT_AND2(_s, d, s1, s2)
 #define	BIT_ANDNOT(_s, d, s)			__BIT_ANDNOT(_s, d, s)
@@ -354,7 +352,11 @@
 #define	BIT_XOR2(_s, d, s1, s2)			__BIT_XOR2(_s, d, s1, s2)
 #define	BIT_ZERO(_s, p)				__BIT_ZERO(_s, p)
 
-#define BITSET_ALLOC(_s, mt, mf)		__BITSET_ALLOC(_s, mt, mf)
+#if defined(_KERNEL)
+#define BITSET_ALLOC(_s, mt, mf)		malloc(__BITSET_SIZE((_s)), mt, (mf))
+#define	BITSET_FREE(p, mt)			free(p, mt)
+#endif /* _KERNEL */
+
 #define	BITSET_FSET(n)				__BITSET_FSET(n)
 #define	BITSET_SIZE(_s)				__BITSET_SIZE(_s)
 #define	BITSET_T_INITIALIZER(x)			__BITSET_T_INITIALIZER(x)
diff --git a/newlib/libc/sys/rtems/include/sys/cpuset.h b/newlib/libc/sys/rtems/include/sys/cpuset.h
index e24bce30c..09278242f 100644
--- a/newlib/libc/sys/rtems/include/sys/cpuset.h
+++ b/newlib/libc/sys/rtems/include/sys/cpuset.h
@@ -71,14 +71,10 @@ typedef cpuset_t cpu_set_t;
 
 #define	_cpu_set_bits(_setsize) (8 * (_setsize))
 
-#define	CPU_ALLOC_SIZE(_num_cpus) (sizeof(long) * __bitset_words(_num_cpus))
+#define CPU_ALLOC_SIZE(_s)		__BITSET_SIZE(_s)
 
 __BEGIN_DECLS
 
-cpu_set_t *__cpuset_alloc(int num_cpus);
-
-void __cpuset_free(cpu_set_t *set);
-
 static __inline cpu_set_t *CPU_ALLOC(int num_cpus)
 {
   return __cpuset_alloc(num_cpus);


                 reply	other threads:[~2022-06-24  5:43 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220624054344.D58053850235@sourceware.org \
    --to=sh@sourceware.org \
    --cc=newlib-cvs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).