This seems to fit the pattern better (e.g. fdopendir()).
I've added weak references to ease the transition, but since it's only
been a few days, we can remove them (and the ObsoleteFiles entries for
the manual pages) before we branch stable/15.
Fixes: deeebfdeca
Sponsored by: Klara, Inc.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D50980
While here, clean up scandir() a bit and improve the documentation.
MFC after: never
Sponsored by: Klara, Inc.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D50935
We only define SIG2STR_MAX with careful visibility, but define the
fortified version unconditionally. It needs to have the same visibility
both places.
Fixes: 3d12567133
Reviewed by: jrtc27, kevans
Sponsored by: Netflix
While the type of va_list and implementation of va_*() psuedo functions
varies (sometimes greatly) by architecture, they will always be defined
by the compiler in a consistant way that does not require machine
dependent handling.
MFC after: 1 week
Reviewed by: imp
Exp-run by: antoine (PR 286274)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1595
Rely in sys/_visible for visibility macros and use __buitin_va_list
instead of __va_list everywere we declare va_list.
Reviewed by: imp
Exp-run by: antoine (PR 286274)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1595
Switch to sys/_visible.h for visibility macros.
Prefer __builtin_offsetof over __offset. sys/cdefs.h always defines
__offsetof to __builtin_offsetof so just use the latter to remove a
dependency on sys/cdefs.h. Realistically, we're never going to care
about a compiler that doesn't supply this builtin.
Add a somewhat questionable guard around the offsetof() definition
because the compiler no longer thinks it the same as a number of other
redundent definitions scattered around (e.g., in the openzfs codebase).
It is actually the same and those defintions likely shouldn't exist at
all, but it's easy to add a guard for now.
Reviewed by: imp
Exp-run by: antoine (PR 286274)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1595
These headers relied in __BEGIN_DECS/__END_DECLS being defined when
sys/_types.h was included, but there's not a requirement that this be
the case.
Reviewed by: imp
Exp-run by: antoine (PR 286274)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1595
The interface is not functional with libthr and returns not supported
error always. There is no point in providing it to userspace or document.
The symbols are kept for ABI compatibility, of course.
Reviewed by: emaste, markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D50376
This is a calque of the NetBSD function of the same name.
MFC after: never
Relontes: yes
Sponsored by: Klara, Inc.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D49979
This adds an `fts_open_b()` variant of `fts_open()` which takes a block
instead of a function pointer.
This was inspired by, and is intended to be compatible with, Apple's
implementation; however, although our FTS and theirs share a common
ancestor, they have diverged significantly. That and the fact that
we still target compilers which don't support blocks means Apple's
implementation was not directly reusable.
This is the second use case for blocks in FreeBSD (the first being
`qsort_b()`, which we use here). This suggest we might want to add
a `COMPILER_FEATURE` for blocks to avoid hardcoding any further
`COMPILER_TYPE` checks.
MFC after: never
Relnotes: yes
Sponsored by: Klara, Inc.
Reviewed by: kevans, theraven, imp
Differential Revision: https://reviews.freebsd.org/D49877
Renumber the private flags so there is a sizeable gap between them and
the public flags, making it easier to add public flags in the future.
These private flags are only ever set or read by FTS itself, so there
is no compatibility issue.
MFC after: 1 week
Sponsored by: Klara, Inc.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D49711
Summary:
This reverts commit d7efac1be1.
This reverts commit 9d0eea9422.
Some ports (specifically Python) define __BSD_VISIBLE themselves, so
the change from __BSD_VISIBLE to __POSIX_VISIBLE >= 202405 makes them
fail.
Reported by: jrtc27, cperciva
Some of the POSIX 202405L functions are already in the system, make
them visible when appropriate.
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D47859
The rpc(3) itself was not designed with multithreading in mind, but we can
actually achieve some parallelism without modifying the library and the
framework. This transport will allow to process RPCs in threads, with
some hacks on the application side (documented in code). We make
reentrable only one method - SVC_REPLY(). Reading and parsing of incoming
calls is still done synchronously. But the actual processing of the calls
can be offloaded to a thread, and once finished the thread can safely
execute svc_sendreply() and the reply would be sent with the correct xid.
Differential Revision: https://reviews.freebsd.org/D48569
To be used by NFS related daemons that provide RPC services to the kernel.
Some implementation details inside the new svc_nl.c.
Reviewed by: rmacklem
Differential Revision: https://reviews.freebsd.org/D48550
This shall be the official transport to connect kernel side RPC clients
to userland side RPC servers. All current kernel side clients that
hijack unix(4) sockets will be converted to it. Some implementation
details are available inside new clnt_nl.c.
The complementary RPC server over netlink(4) coming in next commit.
Reviewed by: rmacklem
Differential Revision: https://reviews.freebsd.org/D48549
GETENTROPY_MAX should be defined in limits.h. EINVAL is the return
value for buflen > GETENTROPY_MAX.
PR: 282783
Reviewed by: markj, asomers, jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D47689
The kernel has had a version of this since
c79cee7136 ("kernel: provide panicky version of __unreachable"), and
userland can benefit from the same. __unreachable is largely
inadequate because it's *not* an assertion of any sort, so we're not
really alerted to a problem that we could've anticipated.
Reviewed by: emaste, imp, jhb, olce
Differential Revision: https://reviews.freebsd.org/D48077
Aborting ATIO while its CTIOs are in progress makes impossible to
handle their completions, making them stuck forever. Detect this
case by checking ctcnt counter and if so instead of aborting just
mark the ATIO as dead to block any new CTIOs. It is not perfect
since the task id can not be reused for some more time, but not
as bad as the task stuck forever.
MFC after: 1 week
Note in the manpage that the 2024 edition finally added ppoll(), and
also add the appropriate declarations for the correct versions of
_POSIX_C_SOURCE (via __POSIX_VISIBLE).
Differential Revision: https://reviews.freebsd.org/D48043
Note in the manpage that the 2024 edition finally added ppoll(), and
also add the appropriate declarations for the correct versions of
_POSIX_C_SOURCE.
Differential Revision: https://reviews.freebsd.org/D48043
C23 has incoporated a small number of POSIX functions, so these
should be exposed for C23, regardless of POSIX.
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D47856
This is similar to chroot(2), but takes a file descriptor instead
of path. Same syscall exists in NetBSD and Solaris. It is part of a larger
patch to make absolute pathnames usable in Capsicum mode, but should
be useful in other contexts too.
Reviewed By: brooks
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D41564
xdr_void() should have type xdrproc_t, make it so.
PR: 280514
Reviewed by: brooks, dim
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D47340
When soft updates began being enabled by default that change carried
over to mdmfs(8) which does not want or need them. This fix ensures
that they are only enabled in mdmfs(8) when requested with the -U flag.
Reported by: Ivan Rozhuk
Tested by: Ivan Rozhuk
PR: 279308
MFC after: 1 week
This is how the other typedefs for rsize_t handle it (in <stddef.h>,
<stdlib.h>, and <string.h>). In particular, we shouldn't have any
rsize_t if a C environment earlier C11 was requested.
This reapplies b35f0aa495, chasing c25e55bcf8, fixing ports build
failures following b35f0aa495 without c25e55bcf8.
PR: 281768
Sponsored by: Tarsnap Backup Inc.
Signed-off-by: Graham Percival
These were supposed to match the visibility of the system's declaration,
but this one was overlooked. Fix it now so that `rsize_t` can be hidden
appropriately.
Reported by: Shawn Webb (and now others)
