if_wg.h was installed via dev/wg in LSUBDIRS and also explicitly. We
want to install only wg/if_wg.h not the other headers, so add dev/wg to
the skip list in the copies and symlinks targets.
PR: 271266
Reviewed by: kevans
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40031
Some points for the future:
- libc is not the right place for sorting algorithms.
Probably libutil is better suited for this purpose or
a dedicated libsort. Should move all sorting algorithms
away from libc eventually.
- CheriBSD uses capabilities for memory access, and could
benefit from a standard memswap() function.
- Do something about qsort() in FreeBSD's libc like:
- Mark it deprecated on FreeBSD, as a first step,
due to missing limits on CPU time.
- Audit the use of qsort() in the FreeBSD base system
and consider swapping to other existing sorting
algorithms.
Discussed with: brooks@
Differential Revision: https://reviews.freebsd.org/D36493
This reverts commit a7469c9c0a.
This reverts commit 7d65a450cd.
This reverts commit 8dcf3a82c5.
The bsort(3) algorithm works by swapping objects, similarly to qsort(3),
and does not require any significant amount of additional memory.
The bsort(3) algorithm doesn't suffer from the processing time issues
known the plague the qsort(3) family of algorithms, and is bounded by
a complexity of O(log2(N) * log2(N) * N), where N is the number of
elements in the sorting array. The additional complexity compared to
mergesort(3) is a fair tradeoff in situations where no memory may
be allocated.
The bsort(3) APIs are identical to those of qsort(3), allowing for
easy drop-in and testing.
The design of the bsort(3) algorithm allows for future parallell CPU
execution when sorting arrays. The current version of the bsort(3)
algorithm is single threaded. This is possible because fixed areas
of the sorting data is compared at a time, and can easily be divided
among different CPU's to sort large arrays faster.
Reviewed by: gbe@, delphij@, pauamma_gundo.com (manpages)
Sponsored by: NVIDIA Networking
Differential Revision: https://reviews.freebsd.org/D36493
These were brought in by the libbind import, but these functions were
never actually implemented anywhere, only header declarations and symbol
map entries were imported.
Fixes: 046c3635cd ("Bring final version of libbind:")
Fixes: e45764721a ("Update our stub resolver to final version of ...")
Reported by: ld.lld 16 being --no-undefined-version by default
Sponsored by: https://www.patreon.com/valpackett
Reviewed by: emaste
Pull request: https://github.com/freebsd/freebsd-src/pull/700
Differential Revision: https://reviews.freebsd.org/D38407
Add mostly glibc and msl compatible secure_getenv. Return NULL if
issetugid() indicates the process is tainted, otherwise getenv(x). The
rational behind this is the fact that many Linux applications use this
function instead of getenv() as it's widely consider a, "best
practice".
Reviewed by: imp, mjg (feedback)
Pull Request: https://github.com/freebsd/freebsd-src/pull/686
Signed-off-by: Lucy Marsh <seafork@disroot.org>
For endian.h to work instead of sys/endian.h, some software needs
byteswap.h available. It must define {__,}byteswap_{16,32,64}.
Included sys/_endian.h to get an appropriate __byteswap16, etc
and defines the new macros in terms of them. Enhance _endian.h
to allow it to be included from here too.
Sponsored by: Netflix
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D32051
Add endian.h. This includes sys/endian.h and then adds extra defines
that glibc defines with double underscores for our
_{BIG,BYTE,LITTLE,PDP}_ENDIAN macros. We also define __FLOAT_WORD_ORDER
to be the same as _BYTE_ENDIAN since FreeBSD doesn't currently define
this, and the default with glibc is exactly this for our platforms.
Move common parts of endian.h and sys/endian.h into sys/_endian.h
to limit namespace pollution from endian.h
All this gives us good compatibility with Linux. There may be one or two
upstreams that haven't integrated the patches I tried to send up.
There are some minor differences:
o The extra glibc macros are not defined. These are all
controlled with either __ at the start, or only defined
when glibc is being built. We also don't define macros
that are used internally in glibc that would pollute
the namespace.
o For complete compatibility, this change must also be
paired with providing a glibc-compatible byteswap.h.
Sponsored by: Netflix
Reviewed by: mhorne, markj, jhb
Differential Revision: https://reviews.freebsd.org/D31962
GCC 12 (unlike GCC 9) does not match a function argument passed to the
old qsort_r() API (as is used in the qsort_r_compat test) to a
function pointer type via __generic. It treats the function type as a
distinct type from a function pointer. As a workaround, add a second
definition of qsort_r for GCC 12 which uses the bare function type.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D37410
The includes build is kind of funky, as we support either copying or
symlinking files into /usr/include. For `copies`, we were supplying
the include/ ${TAG_ARGS}, which puts packages into `FreeBSD-runtime`,
without any consideration to the fact that we're installing headers.
Let's copy the approach that the `symlinks` target uses for now, and
add ",dev" to the TAG_ARGS so that headers at least end up in
FreeBSD-runtime-dev, which is more appropriate. Some of these includes
are actually technically supposed to be in *other* packages and their
INCSGROUP's PACKAGE setting is actually correct, but this is less
trivial to solve. This is a bandaid to fix the immediate problem of
some headers ending up in two different packages.
PR: 267526
Reviewed by: dfr, manu
Differential Revision: https://reviews.freebsd.org/D37256
Rework getaddrinfo(3) to return different error values for unresolvable
names (same as before, EAI_NONAME) and those without a requested addr
(EAI_ADDRFAMILY) when using DNS. This is implemented via an added
error in the nsswitch layer, NS_ADDRFAMILY, which is used only by
getaddrinfo(). The error is passed through nsdispatch(3), but that
routine has no changes to handle this error. The error originates in
the getaddrinfo DNS layer called via nsdispatch(), and is processed
by the search layer that calls nsdispatch().
While here, add a little style to returns near those that were
modified.
Reviewed in https://reviews.freebsd.org/D37139 with related changes.
Reviewed by: bz
MFC after: 1 month
EAI_ADDRFAMILY and EAI_NODATA are not in RFC 3493, but are available
and used in many other systems. It is desirable to have at least one
of them in order to distinguish between names that do not resolve and
those that do not have the requested address type. A change to
getaddrinfo() will use EAI_ADDRFAMILY. Both were "#if 0"; re-enable,
conditioned on __BSD_VISIBLE, and update comments. Also add comments
and __BSD_VISIBLE conditional for the last three EAI errors, which
are not in the RFC or POSIX. Note, all of these are available in
NetBSD and OpenBSD, and EAI_ADDRFAMILY and EAI_NODATA are available
in Linux (glibc).
Reviewed in https://reviews.freebsd.org/D37139 with related changes.
Reviewed by: bz
MFC after: 1 month
This commit brings back the driver from FreeBSD commit
f187d6dfbf plus subsequent fixes from
upstream.
Relative to upstream this commit includes a few other small fixes such
as additional INET and INET6 #ifdef's, #include cleanups, and updates
for recent API changes in main.
Reviewed by: pauamma, gbe, kevans, emaste
Obtained from: git@git.zx2c4.com:wireguard-freebsd @ 3cc22b2
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36909
glibc-based interface.
Unfortunately, the glibc maintainers, despite knowing the existence
of the FreeBSD qsort_r(3) interface in 2004 and refused to add the
same interface to glibc based on grounds of the lack of standardization
and portability concerns, has decided it was a good idea to introduce
their own qsort_r(3) interface in 2007 as a GNU extension with a
slightly different and incompatible interface.
With the adoption of their interface as POSIX standard, let's switch
to the same prototype, there is no need to remain incompatible.
C++ and C applications written for the historical FreeBSD interface
get source level compatibility when building in C++ mode, or when
building with a C compiler with C11 generics support, provided that
the caller passes a fifth parameter of qsort_r() that exactly matches
the historical FreeBSD comparator function pointer type and does not
redefine the historical qsort_r(3) prototype in their source code.
Symbol versioning is used to keep old binaries working.
MFC: never
Relnotes: yes
Reviewed by: cem, imp, hps, pauamma
Differential revision: https://reviews.freebsd.org/D17083
Various RPC functions used a bare pointer in function prototypes to
describe fixed-length buffer arguments but used a fixed-length array
in the function definition. The manual page for these functions
describes the parameters as being fixed-length buffers, so update
the prototypes to match the definitions.
Reviewed by: imp, emaste
Reported by: GCC -Warray-parameter
Differential Revision: https://reviews.freebsd.org/D36757
Add a strverscmp(3) function to libc, a GNU extension I implemented by
reading its glibc manual page. It orders strings following a much more
natural ordering (e.g. "ent1 < ent2 < ent10" as opposed to
"ent1 < ent10 < ent2" with strcmp(3)'s lexicographic ordering).
Also add versionsort(3) for use as scandir(3)'s compar argument.
Update manual page for scandir(3) and add one for strverscmp(3).
Reviewed by: pstef, gbe, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D35807
Add a target to ensure the presence of /usr/include/i386
before we try to install files. In the buildworld/installworld path
it gets created different ways, but for distribute (used in releases)
we need it in the subdir.
(Creating of this the x86, pc, powerpc directories is far too complex.
We should look for ways to simplify it.)
Reported by: lwhsu
Fixes: a09ea2bbc3
Addition to D31491 in order to actually resolve the top root cause.
Currently rpcbind gets contact address from connectionless xprt->xp_p2
member of a transport and will fail to get it when working over
connection oriented transport, leading to a guess game in terms of
contact address on rpcinfo requests like RPCBPROC_GETVERSADDR or
RPCBPROC_GETADDRLIST and poor returns which may influence a user
of a call and specifically reported on OSX clients, which tend to
not provide address hint from rpcinfo request to a server.
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D35220
Install the i386 md_var.h under /usr/include/i386 on amd64 and include
when targeting i386.
This is a mostly kernel-only header required by procstat's ZFS support.
It is pulled in by the i386 machine/counter.h.
Reviewed by: jhb, imp
Install the i386 counter.h under /usr/include/i386 on amd64 and include
when targeting i386.
This is a kernel-only header required by procstat's ZFS support.
Reviewed by: jhb, imp
Install the i386 pcpu_aux.h under /usr/include/i386 on amd64 and include
when targeting i386.
This is a kernel-only header that is required by procstat's ZFS support.
Reviewed by: jhb, imp
Install the i386 pcpu.h under /usr/include/i386 on amd64 and include
when targeting i386.
This is a kernel-only header and should not be required, but
procstat's zfs support includes this with _KERNEL defined.
Reviewed by: jhb, imp
This directory will hold i386-specific headers that are needed for
-m32 support on amd64 and where the amd64 and i386 cases have too
little in common for combining them to make sense. Files to be
installed will come in later commits.
With the currently required set of files, this could be done with
another INCGROUP in include/Makefile, but at least one file that
might want -m32 support (ieeefp.h) conflicts with a files installed
in /usr/include.
Reviewed by: jhb, imp
The gunion(8) utility is used to track changes to a read-only disk on
a writable disk. Logically, a writable disk is placed over a read-only
disk. Write requests are intercepted and stored on the writable
disk. Read requests are first checked to see if they have been
written on the top (writable disk) and if found are returned. If
they have not been written on the top disk, then they are read from
the lower disk.
The gunion(8) utility can be especially useful if you have a large
disk with a corrupted filesystem that you are unsure of how to
repair. You can use gunion(8) to place another disk over the corrupted
disk and then attempt to repair the filesystem. If the repair fails,
you can revert all the changes in the upper disk and be back to the
unchanged state of the lower disk thus allowing you to try another
approach to repairing it. If the repair is successful you can commit
all the writes recorded on the top disk to the lower disk.
Another use of the gunion(8) utility is to try out upgrades to your
system. Place the upper disk over the disk holding your filesystem
that is to be upgraded and then run the upgrade on it. If it works,
commit it; if it fails, revert the upgrade.
Further details can be found in the gunion(8) manual page.
Reviewed by: Chuck Silvers, kib (earlier version)
tested by: Peter Holm
Differential Revision: https://reviews.freebsd.org/D32697
Install headers from LLVM's libunwind in place of the headers from
libcxxrt and allow C applications to use the library.
As part of this, remove include/unwind.h and switch libthr over to
using the installed unwind.h.
Reviewed by: dim, emaste
MFC after: 10 days
Differential Revision: https://reviews.freebsd.org/D34065
I tested the original commit as part of a series that culminates in
removing this header and installing LLVM libunwind's unwind.h in its
place so missed updating this header as was done in b84693501a.
Pointy hat to: jhb
Reported by: kevans
Fixes: 3a502289d3 Use uintptr_t for return type of _Unwind_GetCFA.
This matches the type in other unwind headers (LLVM libunwind,
libcxxrt, glibc).
NB: include/unwind.h is not installed but is only used by libthr
Reviewed by: imp, dim, emaste
Differential Revision: https://reviews.freebsd.org/D34049
Through fixes and improvements our ipfilter sources have diverged
enough to warrant move from contrib into sys/netpil. Now that I'm
planning on implementing MSS clamping as in iptables it makes more
sense to move ipfilter to netpfil.
This is the first of three commits the ipfilter move.
Suggested by glebius on two occaions.
Suggested by and discussed with: glebius
Reviewed by: glebius, kp (for #network)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33510
