Remove wi(4). pccard is going away, and wi only supports PC Card
devices, though it has a minor amount of glue to also support
PCI cards. However, removing the one without removing the other
is hard, so the whole driver is being removed.
Relnotes: Yes
This driver provides raw access to HID devices through uhid(4)-compatible
interface and is based on pre-8.x uhid(4) code. Unlike uhid(4) it does
not take devices in to monopoly ownership and allows parallel access
from other drivers.
hidraw supports Linux's hidraw-compatible interface as well.
Reviewed by: hselasky
Differential revision: https://reviews.freebsd.org/D27992
It will be used by the upcoming HID-over-i2C implementation. Should be
no-op, except hid.ko module dependency is to be added to affected drivers.
Reviewed by: hselasky, manu
Differential revision: https://reviews.freebsd.org/D27867
Using a shell for loop means we have to spawn a separate install(1)
process for each header that is symlinked. This patch uses printf(1) to
generate an argument list that has been prefixed with the correct number
of ../ and then uses a single install(1) invocation.
This reduces the number of execve() calls during make includes from 2442
(with D27622) to 1382. Running `make symlinks` in include/ now spawns 214
processes instead of 1276 without this patch.
Reviewed By: jhb
Differential Revision: https://reviews.freebsd.org/D27723
Instead of using install directly use INCSGROUPS for them.
All those files are the ones we installed when the directory have more .h
files that we don't want to install so they aren't using the LSUBDIR stuff.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D27612
These functions get/set tty winsize respectively, and are trivial wrappers
around corresponding termio ioctls.
The functions are expected to be a part of POSIX.1 issue 8:
https://www.austingroupbugs.net/view.php?id=1151#c3856.
They are currently available in NetBSD and in musl libc.
PR: 251868
Submitted by: Soumendra Ganguly <soumendraganguly@gmail.com>
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D27650
Third-party code tests for strerror_l(3) without specifying
_POSIX_SOURCE, and then expects that the function is prototyped with
_POSIX_SOURCE set to 200112.
Reported and tested by: antoine
Sponsored by: The FreeBSD Foundation
MFC after: 13 days
Only for the arches that provide user-mode TLS.
PR: 251651
Requested by: yuri
Discussed with: emaste, jilles, tijl
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D27495
MFC after: 2 weeks
Provide a way to ask for an opaque version string for a locale_t, so
that potential changes in sort order can be detected. Similar to
ICU's ucol_getVersion() and Windows' GetNLSVersionEx(), this API is
intended to allow databases to detect when text order-based indexes
might need to be rebuilt.
The CLDR version is extracted from CLDR source data by the Makefile
under tools/tools/locale, written into the machine-generated Makefile
under shared/colldef, passed to localedef -V, and then written into
LC_COLLATE file headers. The initial version is 34.0.
tools/tools/locale was recently updated to pull down 35.0, but the
output hasn't been committed under share/colldef yet, so that will
provide the first observable change when it happens. Other versioning
schemes are possible in future, because the format is unspecified.
Reviewed by: bapt, 0mp, kib, yuripv (albeit a long time ago)
Differential Revision: https://reviews.freebsd.org/D17166
We no longer support old versions of GCC. Remove this check by
assuming it's false. That will make the entire expression false. Also
remove support for Intel compiler, it's badly bitrotted. Technically,
this removes support for C89 and K&R from compilers that don't define
_Bool in those compilation environments as well. I'm unaware of any
working compiler today for which that would be relevant (pcc has it
and tcc sadly isn't working for other reasons), though if one
pops up in ports, I'll work to resolve the issue.
Calendar files in LOCALBASE override similarily named ones in the base
system. This could easily be changed if the base system calendars should
have precedence, but it could lead to a violation of POLA since then the
port's files were ignored unless those in base have been deleted.
There was no definition of _PATH_LOCALBASE in paths.h, but verbatim uses
of /usr/local existed for _PATH_DEFPATH. Use _PATH_LOCALBASE here to ease
a consistent modification of this prefix.
Reviewed by: imp, pfg
Differential Revision: https://reviews.freebsd.org/D26882
- Hide ptsname_r under __BSD_VISIBLE for now as the specification
is not finalized at this time.
- Keep Symbol.map sorted.
- Avoid the interposing of ptsname_r(3) from an user application
from breaking ptsname(3) by making the implementation a static
method and call the static function from ptsname(3) instead.
Reported by: kib
Reviewed by: kib, jilles
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D26845
getlogin_r is specified by POSIX to to take a size_t len, not int. Fix our
version to do the same, bump the symbol version due to ABI change and
provide compat.
This was reported to break compilation of Ruby 2.8.
Some discussion about the necessity of the ABI compat did take place in the
review. While many 64-bit platforms would likely be passing it in a 64-bit
register and zero-extended and thus, not notice ABI breakage, some do
sign-extend (e.g. mips).
PR: 247102
Submitted by: Bertram Scharpf <software@bertram-scharpf.de> (original)
Submitted by: cem (ABI compat)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D26335
The primary benefit is maintaining a completely shared
code base with the community allowing FreeBSD to receive
new features sooner and with less effort.
I would advise against doing 'zpool upgrade'
or creating indispensable pools using new
features until this change has had a month+
to soak.
Work on merging FreeBSD support in to what was
at the time "ZFS on Linux" began in August 2018.
I first publicly proposed transitioning FreeBSD
to (new) OpenZFS on December 18th, 2018. FreeBSD
support in OpenZFS was finally completed in December
2019. A CFT for downstreaming OpenZFS support in
to FreeBSD was first issued on July 8th. All issues
that were reported have been addressed or, for
a couple of less critical matters there are
pull requests in progress with OpenZFS. iXsystems
has tested and dogfooded extensively internally.
The TrueNAS 12 release is based on OpenZFS with
some additional features that have not yet made
it upstream.
Improvements include:
project quotas, encrypted datasets,
allocation classes, vectorized raidz,
vectorized checksums, various command line
improvements, zstd compression.
Thanks to those who have helped along the way:
Ryan Moeller, Allan Jude, Zack Welch, and many
others.
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D25872
For libc regcomp, this will be a nop. libregex will take this to mean that
it needs to turn off GNU extensions, effectively switching it back to the
POSIX-compliant libc implementation at runtime.
pthread_get_name_np() and pthread_set_name_np().
This re-applies r361770 after compatibility fixes.
Reviewed by: antoine, jkim, markj
Tested by: antoine (exp-run)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D25117
for pthread_get_name_np() and pthread_set_name_np(), to be
compatible with Linux.
PR: 238404
Proposed and reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D25117
Lot of third-party Linux code uses #include <malloc.h>, expecting to
find the malloc extensions there. Instead of trying to fight them,
accept that attempt to deprecate the header causes more troubles than
solves potential portability issues, and provide our jemalloc
extensions.
PR: 155429
Reviewed by: imp, jhibbits, dab, hselasky, philip, emaste, jilles
Exp-run by: antoine (PR 245366)
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D24297
Do not include stdbool.h, it makes the header incompatible with some
third-party code that typedefs bool manually.
Remove inclusion of strings.h, which typically conflicts with the use
of symbol 'index'.
Separate inclusion of sys/cdefs.h is not needed because sys/types.h
already handles that.
Exp-run by: antoine (PR 245366)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D24297
close_range(min, max, flags) allows for a range of descriptors to be
closed. The Python folk have indicated that they would much prefer this
interface to closefrom(2), as the case may be that they/someone have special
fds dup'd to higher in the range and they can't necessarily closefrom(min)
because they don't want to hit the upper range, but relocating them to lower
isn't necessarily feasible.
sys_closefrom has been rewritten to use kern_close_range() using ~0U to
indicate closing to the end of the range. This was chosen rather than
requiring callers of kern_close_range() to hold FILEDESC_SLOCK across the
call to kern_close_range for simplicity.
The flags argument of close_range(2) is currently unused, so any flags set
is currently EINVAL. It was added to the interface in Linux so that future
flags could be added for, e.g., "halt on first error" and things of this
nature.
This patch is based on a syscall of the same design that is expected to be
merged into Linux.
Reviewed by: kib, markj, vangyzen (all slightly earlier revisions)
Differential Revision: https://reviews.freebsd.org/D21627
This is the foundational change for the routing subsytem rearchitecture.
More details and goals are available in https://reviews.freebsd.org/D24141 .
This patch introduces concept of nexthop objects and new nexthop-based
routing KPI.
Nexthops are objects, containing all necessary information for performing
the packet output decision. Output interface, mtu, flags, gw address goes
there. For most of the cases, these objects will serve the same role as
the struct rtentry is currently serving.
Typically there will be low tens of such objects for the router even with
multiple BGP full-views, as these objects will be shared between routing
entries. This allows to store more information in the nexthop.
New KPI:
struct nhop_object *fib4_lookup(uint32_t fibnum, struct in_addr dst,
uint32_t scopeid, uint32_t flags, uint32_t flowid);
struct nhop_object *fib6_lookup(uint32_t fibnum, const struct in6_addr *dst6,
uint32_t scopeid, uint32_t flags, uint32_t flowid);
These 2 function are intended to replace all all flavours of
<in_|in6_>rtalloc[1]<_ign><_fib>, mpath functions and the previous
fib[46]-generation functions.
Upon successful lookup, they return nexthop object which is guaranteed to
exist within current NET_EPOCH. If longer lifetime is desired, one can
specify NHR_REF as a flag and get a referenced version of the nexthop.
Reference semantic closely resembles rtentry one, allowing sed-style conversion.
Additionally, another 2 functions are introduced to support uRPF functionality
inside variety of our firewalls. Their primary goal is to hide the multipath
implementation details inside the routing subsystem, greatly simplifying
firewalls implementation:
int fib4_lookup_urpf(uint32_t fibnum, struct in_addr dst, uint32_t scopeid,
uint32_t flags, const struct ifnet *src_if);
int fib6_lookup_urpf(uint32_t fibnum, const struct in6_addr *dst6, uint32_t scopeid,
uint32_t flags, const struct ifnet *src_if);
All functions have a separate scopeid argument, paving way to eliminating IPv6 scope
embedding and allowing to support IPv4 link-locals in the future.
Structure changes:
* rtentry gets new 'rt_nhop' pointer, slightly growing the overall size.
* rib_head gets new 'rnh_preadd' callback pointer, slightly growing overall sz.
Old KPI:
During the transition state old and new KPI will coexists. As there are another 4-5
decent-sized conversion patches, it will probably take a couple of weeks.
To support both KPIs, fields not required by the new KPI (most of rtentry) has to be
kept, resulting in the temporary size increase.
Once conversion is finished, rtentry will notably shrink.
More details:
* architectural overview: https://reviews.freebsd.org/D24141
* list of the next changes: https://reviews.freebsd.org/D24232
Reviewed by: ae,glebius(initial version)
Differential Revision: https://reviews.freebsd.org/D24232
utilities so that they will compile with -fno-common.
Started by: Kyle Evans (kevans)
Reviewed by: Kyle Evans (kevans)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D24210
Headers are placed in the -development package via install args in rules
in share/mk/bsd.incs.mk; there is no need to explicitly modify TAGS in
include/Makefile. (Mentioned in review D24139.)
Discussed with: manu
The function allows to peek at the thread exit status and even see
return value, without joining (and thus finally destroying) the target
thread.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation (kib)
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D23676
Among the same justification as the other stdio _unlocked; in addition to an
inline version in <stdio.h>, we must provide a function in libc as well for
the functionality. This fixes the lang/gcc* builds, which want to use the
symbol from libc.
PR: 243810
Reported by: antoine, swills, Michael <michael.adm gmail com>
X-MFC-With: r357284
rand(3)'s standard C API is extremely limiting, but we can do better
than the historical 32-bit state Park-Miller LCG we've shipped since
2001: r73156.
The justification provided at the time for not using random(3) was that
rand_r(3) could not be made to use the same algorithm. That is still
true. However, the irrelevance of rand_r(3) is increasingly obvious.
Since that time, POSIX has marked the interface obsolescent. rand_r(3)
never became part of the standard C library. If not for API
compatibility reasons, I would just remove rand_r(3) entirely.
So, I do not believe it is a problem for rand_r(3) and rand(3) to
diverge.
The 12 ABI is maintained with compatibility definitions, but this
revision does subtly change the API of rand(3). The sequences of
pseudorandom numbers produced in programs built against new versions of
libc will differ from programs built against prior versions of libc.
Reviewed by: kevans, markm
MFC after: no
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D23290
fflush_unlocked is currently desired in ports by sysutils/metalog, and
redefined as the locked fflush.
fputc_unlocked, fputs_unlocked, fread_unlocked, and fwrite_unlocked are
currently desired in ports by devel/elfutils, and redefined as the locked
fputs, fread, and fwrite respectively.
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D23336
to port software written for Linux variant of qsort_r(3).
Reviewed by: kib, arichardson
MFC after: 2 weeks
Relnotes: yes
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D23174
And remove the inline/deprecated attribute use entirely in stdlib.h, from
r355747. The intent was to provide a buildable API transitionary period, but
clearly that was counter-productive.
Reported by: delphij, imp, others
The legacy version of GCC4 currently in base does not support the
parameterized form of this function attribute, as recent introduced in
stdlib.h (r355747).
As we have done for other function attributes with similar compatibility
problems, add a version-compatibile definition in sys/cdefs.h. Note that
Clang defines itself to be GCC 4, so one must check for __clang__ in
addition to __GNUC__ version. On legacy GCC 4, the macro expands to just
the __deprecated__ attribute; on modern GCC or Clang, the macro expands to
the parameterized variant with the message.
Ignoring legacy or unsupported compilers, the macro is also beneficial in
that it is a bit more ergonomic than the full
__attribute__((__deprecated__())) boilerplate.
Reported by: CI (but not tinderbox); imp and others
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D22817
It serves no useful purpose and wasn't as popular as its equally meritless
cousin, srandomdev(3).
Setting aside the problems with rand(3) in general, the problem with this
interface is that the seed isn't shared with the caller (other than by
attacking the output of the generator, which is trivial, but not a hallmark of
pleasant API design). The (arguable) utility of rand(3) or random(3) is as a
semi-fast simulation generator which produces consistent results from a given
seed. These are mutually at odd. Furthermore, sometimes people got the
mistaken impression that a high quality random seed meant a weak generator like
rand(3) or random(3) could be used for things like cryptographic key
generation. This is absolutely not so.
The API was never part of a standard and was not widely used in tree. Existing
in-tree uses have all been removed.
Possible replacement in out of tree codebases:
char buf[3];
time_t t;
time(t);
strftime(buf, sizeof(buf), "%S", gmtime(&t));
srand(atoi(buf));
Relnotes: yes
These functions (sigandset, sigisemptyset, sigorset) are commonly available
in at least musl libc and glibc; sigorset, at least, has proven quite useful
in qemu-bsd-user work for tracking the current process signal mask in a more
self-documenting/aesthetically pleasing manner.
Reviewed by: bapt, jilles, pfg
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22187
Summary:
In rS338751, the check to declare `timespec_get()` for C++17 and higher
was incorrectly done against a `cplusplus` define, while it should have
been `__cplusplus`.
Fix this by using `__cplusplus`, and also bump `__FreeBSD_version` so it
becomes possible to correctly check for `timespec_get()` in upstream
libc++ headers.
Reviewed by: brooks, emaste
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D22735
gets is unsafe and shouldn't be used (for many years now). Leave it in
the existing symbol version so anything that previously linked aginst it
still runs, but do not allow new software to link against it.
(The compatability/legacy implementation must not be static so that
the symbol and in particular the compat sym gets@FBSD_1.0 make it
into libc.)
PR: 222796 (exp-run)
Reported by: Paul Vixie
Reviewed by: allanjude, cy, eadler, gnn, jhb, kib, ngie (some earlier)
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D12298
Since YP protocol definition uses the constant to declare
variable-size opaque byte strings, the change should be binary
compatible with existing installations which do not expose keys or
values larger than 1024 bytes.
All uses of local variables with YPMAXRECORD sizes were removed to
avoid insane stack use. On the other hand, variables with static
lifetime should be fine and only result in increased VA use.
Glibc made same change, increasing the allowed length for keys and
values in YP to 16M, in 2013.
Reviewed by: markj
Discussed with: ian
Sponsored by: Mellanox Technologies
MFC after: 3 weeks
Differential revision: https://reviews.freebsd.org/D20900
This is a variant of mkostemps() which takes a directory descriptor and
returns a descriptor for a tempfile relative to that directory. Unlike
the other mktemp functions, mkostempsat() can be used in capability
mode.
Reviewed by: cem
Discussed with: brooks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D21031
copy_file_range(2) is a Linux compatible syscall created by r350315.
Reviewed by: kib, asomers
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D20584
NANDFS has been broken for years. Remove it. The NAND drivers that
remain are for ancient parts that are no longer relevant. They are
polled, have terrible performance and just for ancient arm
hardware. NAND parts have evolved significantly from this early work
and little to none of it would be relevant should someone need to
update to support raw nand. This code has been off by default for
years and has violated the vnode protocol leading to panics since it
was committed.
Numerous posts to arch@ and other locations have found no actual users
for this software.
Relnotes: Yes
No Objection From: arch@
Differential Revision: https://reviews.freebsd.org/D20745
ioctl definitions and related datatypes that allow userland control of pwm
hardware via the pwmc device. The new name and location better reflects its
assocation with a single device driver.
the file associated with the given file descriptor.
Reviewed by: kib, asomers
Reviewed by: cem, jilles, brooks (they reviewed previous version)
Discussed with: pjd, and many others
Differential Revision: https://reviews.freebsd.org/D14567
Error messages in gai_strerror(3) vary largely among OSs.
For new software we largely replaced the obsoleted EAI_NONAME and
with EAI_NODATA but we never updated the corresponding message to better
match the intended use. We also have references to ai_flags and ai_family
which are not very descriptive for non-developer end users.
Bring new new error messages based on informational RFC 3493, which has
obsoleted RFC 2553, and make them consistent among the header adn
manpage.
MFC after: 1 month
Differentical Revision: D18630
NL_ARGMAX is the maximum number of positional arguments supported by
printf(3). Prior to r308145 it was declared as 99 and not enforced.
r308145 added enforcement and increased the value to 64k.
Unfortunately, development versions of PostgreSQL used the system
definition to allocate and zero an NL_ARGMAX * 4 sized array on the
stack of its snprintf implementation with measurable performance
impacts. This has been fixed in new PostgreSQL versions, but it is
possible that other programs suffer from this problem.
A value of 4096 puts us on par with Linux and is certainly large enough
for any reasonable program.
Reviewed by: mjg
Reported by: mjg
Approved by: re (gjb)
Differential revision: https://reviews.freebsd.org/D17387
Differential revision: https://reviews.freebsd.org/D8286
Users of arc4random(3) should never call them directly.
All ports tree usage was fixed as part of bug 230756.
Relnotes: yes
Approved by: re (marius), exp-run (bug 230756 by portmgr antoine)
Otherwise this step will fail on a Linux host due to missing "wheel" group
Approved By: brooks (mentor)
Differential Revision: https://reviews.freebsd.org/D16841
ObsoleteFiles.inc:
Remove manual pages for arc4random_addrandom(3) and
arc4random_stir(3).
contrib/ntp/lib/isc/random.c:
contrib/ntp/sntp/libevent/evutil_rand.c:
Eliminate in-tree usage of arc4random_addrandom().
crypto/heimdal/lib/roken/rand.c:
crypto/openssh/config.h:
Eliminate in-tree usage of arc4random_stir().
include/stdlib.h:
Remove arc4random_stir() and arc4random_addrandom() prototypes,
provide temporary shims for transistion period.
lib/libc/gen/Makefile.inc:
Hook arc4random-compat.c to build, add hint for Chacha20 source for
kernel, and remove arc4random_addrandom(3) and arc4random_stir(3)
links.
lib/libc/gen/arc4random.c:
Adopt OpenBSD arc4random.c,v 1.54 with bare minimum changes, use the
sys/crypto/chacha20 implementation of keystream.
lib/libc/gen/Symbol.map:
Remove arc4random_stir and arc4random_addrandom interfaces.
lib/libc/gen/arc4random.h:
Adopt OpenBSD arc4random.h,v 1.4 but provide _ARC4_LOCK of our own.
lib/libc/gen/arc4random.3:
Adopt OpenBSD arc4random.3,v 1.35 but keep FreeBSD r114444 and
r118247.
lib/libc/gen/arc4random-compat.c:
Compatibility shims for arc4random_stir and arc4random_addrandom
functions to preserve ABI. Log once when called but do nothing
otherwise.
lib/libc/gen/getentropy.c:
lib/libc/include/libc_private.h:
Fold __arc4_sysctl into getentropy.c (renamed to arnd_sysctl).
Remove from libc_private.h as a result.
sys/crypto/chacha20/chacha.c:
sys/crypto/chacha20/chacha.h:
Make it possible to use the kernel implementation in libc.
PR: 182610
Reviewed by: cem, markm
Obtained from: OpenBSD
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D16760
This basically adds makes use of the C99 restrict keyword, and also
adds some 'const's to four threading functions: pthread_mutexattr_gettype(),
pthread_mutexattr_getprioceiling(), pthread_mutexattr_getprotocol(), and
pthread_mutex_getprioceiling. The changes are in accordance to POSIX/SUSv4-2018.
Hinted by: DragonFlyBSD
Relnotes: yes
MFC after: 1 month
Differential Revision: D16722
The function retrieves the thread name previously set by
pthread_set_name_np(3). The name is cached in the process memory.
Requested by: Willem Jan Withagen <wjw@digiware.nl>
Man page update: Yuri Pankov <yuripv@yuripv.net>
Reviewed by: ian (previous version)
Discussed with: arichardson, bjk (man page)
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D16702
While nothing was wrong with libnvpair.h, libzfs_core.h was only guarded by
MK_CDDL rather than MK_CDDL && MK_ZFS. Rather than ugl'if'ying
include/Makefile to impose the extra restriction, just move the non-sys/
includes into INCS with the respect lib builds.
This has the added bonus of allowing third party packagers to try and split
these libs out of the FreeBSD-runtime package, if they are so inclined.
The sys/ include was left alone- generally userland libraries shouldn't
install kernel headers.
MFC after: 1 week
Bring in the functionality for timespec_get from NetBSD. I've lightly
edited the .c file to remove _DIAGASSERT because FreeBSD doesn't have
that functionality and the typical #define'ing it to assert isn't
right here. The man page is verbatim from NetBSD, but will be revised
as part of a larger cleanup of the time man pages (they are
inconsistent and vague in all the wrong places).
Differential Review: https://reviews.freebsd.org/D16649
This corresponds to the latest status (hasn't changed in 9+
years) from openbsd of ld80/ld128 powl, and source cpowf, cpow,
cpowl (the complex power functions for float complex, double
complex, and long double complex) which are required for C99
compliance and were missing from FreeBSD. Also required for
some numerical codes using complex numbered Hamiltonians.
Thanks to jhb for tracking down the issue with making
weak_reference compile on powerpc.
When asked to review, bde said "I don't like it" - but
provided no actionable feedback or superior implementations.
Discussed with: jhb
Submitted by: jmd
Differential Revision: https://reviews.freebsd.org/D15919
quatactl(2) mechanism. (Read-only at this point, however.)
In particular, this is to allow rpc.rquotad query quotas
for NFS mounts, allowing users to see their quotas on the
hosts using the datasets.
The changes specifically:
* Add new RPC entry points for querying quotas.
* Changes the library routines to allow non-UFS quotas.
* Changes rquotad to check for quotas on mounted filesystems,
rather than being limited to entries in /etc/fstab
* Lastly, adds a VFS entry-point for ZFS to query quotas.
Note that this makes one unavoidable behavioural change: if quotas
are enabled, then they can be queried, as opposed to the current
method of checking for quotas being specified in fstab. (With
ZFS, if there are user or group quotas, they're used, always.)
Reviewed by: delphij, mav
Approved by: mav
Sponsored by: iXsystems Inc
Differential Revision: https://reviews.freebsd.org/D15886
These are documented in `time2posix.3` but the symbols are not actually
visible. Since these are not POSIX hide them behind _BSD_VISIBLE.
Reviewed by: wollman
Differential Revision: https://reviews.freebsd.org/D15530
This is a component of a system which lets the kernel dump core to
a remote host after a panic, rather than to a local storage device.
The server component is available in the ports tree. netdump is
particularly useful on diskless systems.
The netdump(4) man page contains some details describing the protocol.
Support for configuring netdump will be added to dumpon(8) in a future
commit. To use netdump, the kernel must have been compiled with the
NETDUMP option.
The initial revision of netdump was written by Darrell Anderson and
was integrated into Sandvine's OS, from which this version was derived.
Reviewed by: bdrewery, cem (earlier versions), julian, sbruno
MFC after: 1 month
X-MFC note: use a spare field in struct ifnet
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D15253
This driver supports legacy, 32-bit PCI devices, and had an ambiguous
license. Supported devices were already reported to be rare in 2003
(when an earlier version of the driver was removed in r123201).
Reviewed by: rgrimes
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D15245
These have been found to be practically useless. We were actually
following the Android bionic library and had some interest in replicating
the same warnings and behaviour but Android has since removed them.
We are still keeping some uses of nullability attributes in other headers,
somewhat in line with Apple's libc.
MFC after: 1 week
Hinted by: bionic (git 3f66e74b903905e763e104396aff52a81718cfde)
In my attempt to limit the commit in r331936 to only the gets_s()
commit and not include unrelated patches in my tree, this patch
was missed.
Reported by: pfg
MFC after: 2 weeks
X-MFC with: r331936
Differential Revision: https://reviews.freebsd.org/D12785
summits at BSDCan and BSDCam in 2017.
The TCP Blackbox Recorder allows you to capture events on a TCP connection
in a ring buffer. It stores metadata with the event. It optionally stores
the TCP header associated with an event (if the event is associated with a
packet) and also optionally stores information on the sockets.
It supports setting a log ID on a TCP connection and using this to correlate
multiple connections that share a common log ID.
You can log connections in different modes. If you are doing a coordinated
test with a particular connection, you may tell the system to put it in
mode 4 (continuous dump). Or, if you just want to monitor for errors, you
can put it in mode 1 (ring buffer) and dump all the ring buffers associated
with the connection ID when we receive an error signal for that connection
ID. You can set a default mode that will be applied to a particular ratio
of incoming connections. You can also manually set a mode using a socket
option.
This commit includes only basic probes. rrs@ has added quite an abundance
of probes in his TCP development work. He plans to commit those soon.
There are user-space programs which we plan to commit as ports. These read
the data from the log device and output pcapng files, and then let you
analyze the data (and metadata) in the pcapng files.
Reviewed by: gnn (previous version)
Obtained from: Netflix, Inc.
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D11085
The general idea here is to provide userspace programs with well-defined
sources of entropy, in a fashion that doesn't require opening a new file
descriptor (ulimits) or accessing paths (/dev/urandom may be restricted
by chroot or capsicum).
getrandom(2) is the more general API, and comes from the Linux world.
Since our urandom and random devices are identical, the GRND_RANDOM flag
is ignored.
getentropy(3) is added as a compatibility shim for the OpenBSD API.
truss(1) support is included.
Tests for both system calls are provided. Coverage is believed to be at
least as comprehensive as LTP getrandom(2) test coverage. Additionally,
instructions for running the LTP tests directly against FreeBSD are provided
in the "Test Plan" section of the Differential revision linked below. (They
pass, of course.)
PR: 194204
Reported by: David CARLIER <david.carlier AT hardenedbsd.org>
Discussed with: cperciva, delphij, jhb, markj
Relnotes: maybe
Differential Revision: https://reviews.freebsd.org/D14500
ConnectX-4/5 devices in mlx5core.
The dump is obtained by reading a predefined register map from the
non-destructive crspace, accessible by the vendor-specific PCIe
capability (VSC). The dump is stored in preallocated kernel memory and
managed by the mlx5tool(8), which communicates with the driver using a
character device node.
The utility allows to store the dump in format
<address> <value>
into a file, to reset the dump content, and to manually initiate the
dump.
A call to mlx5_fwdump() should be added at the places where a dump
must be fetched automatically. The most likely place is right before a
firmware reset request.
Submitted by: kib@
MFC after: 1 week
Sponsored by: Mellanox Technologies
nothing - it was checking for ENXIO, which, with devfs, is no longer
returned - and was badly placed anyway, and replaces it with similar
one that works, and is done just before starting getty, instead of being
done when rereading ttys(5).
From the practical point of view, this makes init(8) handle disappearing
terminals (eg /dev/ttyU*) gracefully, without unneccessary getty restarts
and resulting error messages.
Reviewed by: imp@
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D14307
We don't support float in the boot loaders, so don't include
interfaces for float or double in systems headers. In addition, take
the unusual step of spiking double and float to prevent any more
accidental seepage.
We removed the nonnull attributes from our headers long ago, but still
__printflike() includes it implicitly. This will cause the NULL check to
be optimized away in higher -O levels and it will also trigger a
-Wnonnull-compare warning.
Avoid warning with it in vwarnx().
Obtained from: DragonfLyBSD (git 6329e2f68af73662a1960240675e796ab586bcb1)
The GCC attribute causes a warning to be emitted if a caller of the
function with this attribute does not use its return value. Unlike the
traditional realloc, with reallocf(3) we don't have to check for NULL
values but we still have to make sure the result is used.
MFC after: 3 days
The daemonfd function is equivalent to the daemon(3) function expect that
arguments are descriptors. For example dhclient(8) which is sandboxed is
unable to open /dev/null to close stdio instead it's allows to fail
daemon(3) function to close the descriptors and then do it explicit in code.
Instead of such hacks we can use now daemonfd.
This API can be also helpful to migrate system to platforms like CheriBSD.
Reviewed by: brooks@, bcr@, jilles@ (earlier version)
Differential Revision: https://reviews.freebsd.org/D13433
Now that the POSIX working group is going to require that basename(3)
and dirname(3) are thread-safe in future revisions of the standard,
there is even less of a need to provide basename_r(3). Remove this
function to prevent people from writing code that only builds on
FreeBSD and Bionic.
Removing this function seems to break exactly one port: sbruno@'s
qemu-user-static. I will send him a pull request on GitHub in a bit.
__FreeBSD_version will not be bumped, as any value from 2017 can be used
to test for the presence of a thread-safe basename(3)/dirname(3).
PR: https://bugs.freebsd.org/224016
