The changes to the bitset macros allowed sched.h to be included
into userland programs without name space pollution due to BIT_*
and BITSET_* macros.
The definition of a "struct bitset" had been overlooked. This name
space pollution caused the build of port print/miktex to fail.
This commit makes the definition of struct bitset depend on the
same condition as the visibility of the BIT_* and BITSET_* macros,
i.e. needs _KERNEL or _WANT_FREEBSD_BITSET to be defined before
including sys/_bitset.h.
It has been tested with "make universe" since a prior attempt to
fix the issue broke the PowerPC64 kernel build.
This commit shall be MFCed together with commit 5e04571cf3c.
Reported by: arrowd
MFC after: 1 month
It caused kernel build for PowerPC64 to fail.
A different patch is being tested with make universe to make sure it
works on all architectures.
MFC after: 1 month<N [day[s]|week[s]|month[s]]. Request a reminder email>
There is a reference to malloc() in #define __BITSET_ALLOC. Even
though this macro is only defined but not used, it causes the lang/gcc
ports to fail. The gcc ports "poison" a number of functions including
malloc() and prevent their use (including in macro definitions).
This commit moved the declaration of __BITSET_ALLOC into the
conditional block that depends on _KERNEL or _WANT_FREEBSD_BITSET
being defined.
There is no use of __BITSET_ALLOC in the FreeBSD sources, and userland
programs that want to use BITSEC_ALLOC will define _WANT_FREEBSD_BITSET
anyway.
This patch has been tested by building lang/gcc11 and a successful
make buildworld.
This commit shall be MFCed together with commit 5e04571cf3c.
MFC after: 1 month
The changes to the bitset macros allowed sched.h to be included into
userland programs without name space pollution due to BIT_* and
BITSET_* macros.
The definition of a global variable "bitset" had been overlooked.
This name space pollution caused a compile failure in print/miktex.
This commit renames the bitset variable to __bitset with the same
mapping back to the bitset if _KERNEL or _WANT_FREEBSD_BITSET is
defined.
This fix has been suggested by kib. It has been tested to let the
build of the print/miktex port succeed and to not break buildworld.
This commit shall be MFCed together with commit 5e04571cf3c.
Reported by: arrowd
MFC after: 1 month
Add two underscore characters "__" to names of BIT_* and BITSET_*
macros to move them to the implementation name space and to prevent
a name space pollution due to BIT_* macros in 3rd party programs with
conflicting parameter signatures.
These prefixed macro names are used in kernel header files to define
macros in e.g. sched.h, sys/cpuset.h and sys/domainset.h.
If C programs are built with either -D_KERNEL (automatically passed
when building a kernel or kernel modules) or -D_WANT_FREENBSD_BITSET
(or this macros is defined in the source code before including the
bitset macros), then all macros are made visible with their previous
names, too. E.g., both __BIT_SET() and BIT_SET() are visible with
either of _KERNEL or _WANT_FREEBSD_BITSET defined.
The main reason for this change is that some 3rd party sources
including sched.h have been found to contain conflicting BIT_*
macros.
As a work-around, parts of shed.h have been made conditional and
depend on _WITH_CPU_SET_T being set when sched.h is included.
Ports that expect the full functionality provided by sched.h need
to be built with -D_WITH_CPU_SET_T. But this leads to conflicts if
BIT_* macros are defined in that program, too.
This patch set makes all of sched.h visible again without this
parameter being passed and without any name space pollution due
to BIT_* macros becoming visible when sched.h is included.
This patch set will be backported to the STABLE branches, but ports
will need to use -D_WITH_CPU_SET_T as long as there are supported
releases that do not contain these patches.
Reviewed by: kib, markj
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D33235
This implementation is faster and doesn't modify the cpuset, so it lets
us avoid some unnecessary copying as well. No functional change
intended.
This is a re-application of commit
9068f6ea697b1b28ad1326a4c7a9ba86f08b985e.
Reviewed by: cem, kib, jhb
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32029
Eliminate the nested loops and re-implement following a suggestion from
rlibby.
Add some simple regression tests.
Reviewed by: rlibby, kib
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32472
This reverts commit 9068f6ea697b1b28ad1326a4c7a9ba86f08b985e.
The underlying macro needs to be reworked to avoid problems with control
flow statements.
Reported by: rlibby
This implementation is faster and doesn't modify the cpuset, so it lets
us avoid some unnecessary copying as well. No functional change
intended.
Reviewed by: cem, kib, jhb
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32029
These allow one to non-destructively iterate over the set or clear bits
in a bitset. The motivation is that we have several code fragments
which iterate over a CPU set like this:
while ((cpu = CPU_FFS(&cpus)) != 0) {
cpu--;
CPU_CLR(cpu, &cpus);
<do something>;
}
This is slow since CPU_FFS begins the search at the beginning of the
bitset each time. On amd64 and arm64, CPU sets have size 256, so there
are four limbs in the bitset and we do a lot of unnecessary scanning.
A second problem is that this is destructive, so code which needs to
preserve the original set has to make a copy. In particular, we have
quite a few functions which take a cpuset_t parameter by value, meaning
that each call has to copy the 32 byte cpuset_t.
The new macros address both problems.
Reviewed by: cem, kib
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32028
iflib now supports mapping each (TX,RX) queue pair to the same CPU
(default), to separate CPUs, or to a pair of physical and logical CPUs
that share the same L2 cache. The mapping mechanism supports unequal
numbers of TX and RX queues, with the excess queues always being
mapped to consecutive physical CPUs. When the platform cannot
distinguish between physical and logical CPUs, all are treated as
physical CPUs. See the comment on get_cpuid_for_queue() for the
entire matrix.
The following device-specific tunables influence the mapping process:
dev.<device>.<unit>.iflib.core_offset (existing)
dev.<device>.<unit>.iflib.separate_txrx (existing)
dev.<device>.<unit>.iflib.use_logical_cores (new)
The following new, read-only sysctls provide visibility of the mapping
results:
dev.<device>.<unit>.iflib.{t,r}xq<n>.cpu
When an iflib driver allocates TX softirqs without providing reference
RX IRQs, iflib now binds those TX softirqs to CPUs using the above
mapping mechanism (that is, treats them as if they were TX IRQs).
Previously, such bindings were left up to the grouptaskqueue code and
thus fell outside of the iflib CPU mapping strategy.
Reviewed by: kbowling
Tested by: olivier, pkelsey
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D24094
That is, provide wrappers around the atomic_testandclear and
atomic_testandset primitives.
Submitted by: jeff
Reviewed by: cem, kib, markj
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D22702
An upcoming patch to use the bitset macros for tracking vm page
dump information could conceivably need more than INT_MAX bits.
Expand the bit type to long so that the extra range is available
on 64-bit platforms where it would most likely be needed.
CPUSET_COUNT and DOMAINSET_COUNT are also modified to remain of
type `int`.
Reviewed by: kib, markj
Approved by: scottl (implicit)
MFC after: 1 week
Sponsored by: Ampere Computing, Inc.
Differential Revision: https://reviews.freebsd.org/D26190
s/BIT_NAND/BIT_ANDNOT/, and for CPU and DOMAINSET too. The actual
implementation is "and not" (or "but not"), i.e. A but not B.
Fortunately this does appear to be what all existing callers want.
Don't supply a NAND (not (A and B)) operation at this time.
Discussed with: jeff
Reviewed by: cem
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D22791
We have a couple optimizations for when the bitset is known to be just
one word. But with dynamically sized bitsets, it was actually more work
to determine the size than just to do the necessary computation. Now,
only use the optimization when the size is known to be constant.
Reviewed by: markj
Discussed with: jeff
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D22639
This code has not been updated since 2016, and it looks like it has
rotted quite a bit since. It does not build against the current set
of phoenix sources -- I had to hack both the kernel headers and the
newlib headers up to get it to build, and I still have no idea if it
actually links or runs. It seems like the project itself has moved
away from newlib and to its own C library:
https://phoenix-rtos.com/documentation/libc/README.md
So since there's no interest from the phoenix folks to maintain this,
and it has a significant amount of non-standard code that we try to
keep up-to-date (without actually testing it), just punt it all.
I've had this lying around for probably a year or two at this point.
It just changes all the instance of "errno" from a common symbol to an
extern. I can't offhand recall where the actual definition is, but it
certainly exists in the generic code.
Convert all the libc/ subdir makes into the top-level Makefile. This
allows us to build all of libc from the top Makefile without using any
recursive make calls. This is faster and avoids the funky lib.a logic
where we unpack subdir archives to repack into a single libc.a. The
machine override logic is maintained though by way of Makefile include
ordering, and source file accumulation in libc_a_SOURCES.
There's a few dummy.c files that are no longer necessary since we aren't
doing the lib.a accumulating, so punt them.
The winsup code has been pulling the internal newlib ssp library out,
but that doesn't exist anymore, so change that to pull the objects.
This kills off the last configure script under libc/ and folds it
into the top newlib configure script. The a lot of the logic was
already in the top configure script, so move what's left into a
libc/acinclude.m4 file.
Remove dependency on __sdidinit member of struct _reent to check
object initialization. Like __sdidinit, the __cleanup member of
struct _reent is initialized in the __sinit() function. Checking
initialization against __cleanup serves the same purpose and will
reduce overhead in the __sfp() function in a follow up patch.
The crt0.o was handled in a subdir-by-subdir basis: it would be compiled
in one (e.g. libc/sys/$arch/), then copied up one level (libc/sys/), then
copied up another (libc/) before finally being copied & installed in the
top newlib dir. The libc/sys/ copy was cleaned up, and then the top dir
was changed to copy it directly out of the libc/sys/$arch/ dir. But the
libc/sys/ copy to libc/ was left behind. Clean that up now too.
When migrating the manual to the top-level, the include order was
sorted by name of the subdir. But this changed the chapter order
of the manual in the process. Change the sorting back to match
existing chapters and update the comments to explain.
The top-level newlib dir already takes care of recursing into the
sys/xxx/include/ subdirs and installing any headers found, so the
rtems subdir doesn't need to do this itself.
This is used in a bunch of places, but nowhere is it ever set, and
nowhere can I find any documentation, nor can I find any other project
using it. So delete the flags to simplify.
These targets don't actually cross-compile -- they try to pull some
objects out of the host's /lib/libc.a, /lib/libm.a, and /lib/crt0.o
directly and merge them into newlib's own libraries. This is hard
to keep working and impossible to test. Considering the vintage of
such targets, and gcc dropping them many many years ago, drop them
from newlib too. This will make cleaning up the build a lot easier.
The machine/{configure,Makefile} files exist only to fan out to the
specific machine/$arch/ subdir. We already have all that same info
in the phoenix/ dir itself, so by moving the recursive configure and
make calls into it, we can cut off this logic entirely and save the
overhead.
These were never added to the tree, and as we transition from autoconf
to automake, it really wants the latter subdirs to always exist. These
don't, so delete the logic.
This was only ever used for i?86-pc-linux-gnu targets, but that's been
broken for years, and has since been dropped. So clean this up too.
This also deletes the funky objectlist logic since it only existed for
the libtool libraries. Since it was the only thing left in the small
Makefile.shared file, we can punt that too.
This was only used by the i?86-pc-linux-gnu target which we've removed,
and even though it's using a "sys/linux/" dir to make it sound like it
only depends on the Linux kernel, it's actually tied to glibc APIs built
on top of Linux. Since the code relies on internal glibc APIs and has
been broken for some time, punt it all. If someone wants to bring it
back, they can try and actually keep the Linux-vs-glibc APIs separate.
Now that we use AC_NO_EXECUTABLES, and we require a recent version of
autoconf, we don't need to define our own copies of these macros. So
switch to the standard AC_PROG_CC.
This logic was added to libc & libm to get it working again after some
reworks in the CPP handling, but now that that's settled, let's move
this to the common newlib configure logic. This will make it easier
to consolidate all the configure calls into the top-level newlib dir.
This does create a lot of noise in the generate scripts, but that's
because of the ordering of the calls, not because of correctness. We
will try to draw that back down in follow up commits as we modernize
the toolchain calls in here.
THe stdio subdir is actually required by the documentation. The
stdio/def is handled dynamically, but libc.texi always expects it
to be included, and fails if it isn't. So making it required when
building docs is safe.
The xdr subdir is handled dynamically, but it doesn't include any
docs, so the dynamic logic isn't (currently) adding any value. So
making it required when building docs is safe.
That leaves: iconv, stdio64, posix, and signal subdirs. The chapters
have a little disclaimer saying they are system-dependent, but even
then, imo having stable manuals regardless of the target is preferable,
and we can add more disclaimer language to these chapters if we want.
This doesn't touch the man page codepaths, just the info/pdf.
Let automake manage whether the objects are included in lib.a. This
fixes failures after to commit 71086e8b2d
("newlib: delete (most) redundant lib_a_CCASFLAGS=$(AM_CCASFLAGS)") due
to automake generating different set of implicit rules, and the code in
here assuming the names of the generated objects.
When we had configure scripts in subdirs, the newlib_basedir value
was computed relative to that, and it'd be the same when used in the
Makefile in the same dir. With many subdir configure scripts removed,
the top-level configure & Makefile can't use the same relative path.
So switch the subdir Makefiles over to abs_newlib_basedir when they
use -I to find source headers.
Do this for all subdirs, even ones with configure scripts and where
newlib_basedir works. This makes the code consistent, and avoids
surprises if the configure script is ever removed in the future as
part of merging to the higher level.
Some of the subdirs were using -I$(newlib_basedir)/../newlib/ for
some reason. Collapse those too since newlib_basedir points to the
newlib source tree already.
Stefan Eßer
Konstantin Belousov
Mark Johnston
Patrick Kelsey
Ryan Libby
D Scott Phillips
Jeff Roberson
Sebastian Huber
Mike Frysinger
Jeff Law
Matt Joyce