| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
|
|
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32901
|
|
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
|
|
Reviewed by: kib
Approved by: scottl (implicit)
MFC after: 1 week
Sponsored by: Ampere Computing, Inc.
Differential Revision: https://reviews.freebsd.org/D26128
|
|
Reviewed by: dim, markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D22898
|
|
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 significantly shrinks embedded slab structures.
Reviewed by: markj, rlibby (prior version)
Differential Revision: https://reviews.freebsd.org/D22584
|
|
|
|
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.
|
|
Merge sys/phoenix/ configure logic into libc/ itself. This kills
off the last lingering script in this tree (other than libc itself).
|
|
The machine configure scripts are all effectively stub scripts that
pass the higher level options to its own makefile.
|
|
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.
|
|
These configure scripts hardcode some settings, so move them to the
Makefile to simplify so we can drop the configure scripts entirely.
|
|
These don't work at all now that we've completely upgraded autotools.
|
|
This was needed only to support libtool in case objects ended in .lo
instead of .o, but we dropped libtool, so drop this too.
|
|
This was needed only to support libtool in case the library ended in
.la instead of .a, but we dropped libtool, so drop this too.
|
|
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.
|
|
We require autoconf-2.69 now, so we don't need this old install hack.
|
|
Now that we rely on AC_NO_EXECUTABLES to disable link tests, we don't
need this hack to disable exeext probing.
|
|
Now that we require automake-1.15, we can use this macro rather than
do the tool search ourselves.
|
|
Now that we require a recent automake version, rely on it to provide AS
and CCAS and CCASFLAGS for us.
|
|
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.
|
|
Now that the top-level makefile handles these, don't need to copy
these into every single subdir.
|
|
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 71086e8b2d70c1e71a8372f35d9901505fc72905
("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.
|
|
When using the top-level configure script but subdir Makefiles, the
newlib_basedir value gets a bit out of sync: it's relative to where
configure lives, not where the Makefile lives. Move the abs setting
from the top-level configure script into acinclude.m4 so we can rely
on it being available everywhere. Although this commit doesn't use
it anywhere, just lays the groundwork.
|
|
The machine configure scripts are all effectively stub scripts that
pass the higher level options to its own makefile. There were only
three doing custom tests. The rest were all effectively the same as
the libc/ configure script.
So instead of recursively running configure in all of these subdirs,
generate their makefiles from the top-level configure. For the few
unique ones, deploy a pattern of including subdir logic via m4:
m4_include([machine/nds32/acinclude.m4])
Some of the generated machine makefiles have a bunch of extra stuff
added to them, but that's because they were inconsistent in their
configure libtool calls. The top-level has it, so it exports some
new vars to the ones that weren't already.
|
|
The sys configure scripts are almost all effectively stub scripts that
pass the higher level options to its own makefile. The phoenix & linux
ones are a bit more complicated with nested subdirs, so those have been
left alone for now. Plus, I don't really have a way of testing them.
|
