tun(4) and tap(4) share the same general management interface and have a lot
in common. Bugs exist in tap(4) that have been fixed in tun(4), and
vice-versa. Let's reduce the maintenance requirements by merging them
together and using flags to differentiate between the three interface types
(tun, tap, vmnet).
This fixes a couple of tap(4)/vmnet(4) issues right out of the gate:
- tap devices may no longer be destroyed while they're open [0]
- VIMAGE issues already addressed in tun by kp
[0] emaste had removed an easy-panic-button in r240938 due to devdrn
blocking. A naive glance over this leads me to believe that this isn't quite
complete -- destroy_devl will only block while executing d_* functions, but
doesn't block the device from being destroyed while a process has it open.
The latter is the intent of the condvar in tun, so this is "fixed" (for
certain definitions of the word -- it wasn't really broken in tap, it just
wasn't quite ideal).
ifconfig(8) also grew the ability to map an interface name to a kld, so
that `ifconfig {tun,tap}0` can continue to autoload the correct module, and
`ifconfig vmnet0 create` will now autoload the correct module. This is a
low overhead addition.
(MFC commentary)
This may get MFC'd if many bugs in tun(4)/tap(4) are discovered after this,
and how critical they are. Changes after this are likely easily MFC'd
without taking this merge, but the merge will be easier.
I have no plans to do this MFC as of now.
Reviewed by: bcr (manpages), tuexen (testing, syzkaller/packetdrill)
Input also from: melifaro
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D20044
device_printf does multiple calls to printf allowing other console messages to
be inserted between the device name, and the rest of the message. This change
uses sbuf to compose to two into a single buffer, and prints it all at once.
It exposes an sbuf drain function (drain-to-printf) for common use.
Update documentation to match; some unit tests included.
Submitted by: jmg
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D16690
By default, cores are now assigned to queues in a sequential
manner rather than all NICs starting at the first core. On a four-core
system with two NICs each using two queue pairs, the nic:queue -> core
mapping has changed from this:
0:0 -> 0, 0:1 -> 1
1:0 -> 0, 1:1 -> 1
To this:
0:0 -> 0, 0:1 -> 1
1:0 -> 2, 1:1 -> 3
Additionally, a device can now be configured to use separate cores for TX
and RX queues.
Two new tunables have been added, dev.X.Y.iflib.separate_txrx and
dev.X.Y.iflib.core_offset. If core_offset is set, the NIC is not part
of the auto-assigned sequence.
Reviewed by: marius
MFC after: 2 weeks
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D20029
This GRE-in-UDP encapsulation allows the UDP source port field to be
used as an entropy field for load-balancing of GRE traffic in transit
networks. Also most of multiqueue network cards are able distribute
incoming UDP datagrams to different NIC queues, while very little are
able do this for GRE packets.
When an administrator enables UDP encapsulation with command
`ifconfig gre0 udpencap`, the driver creates kernel socket, that binds
to tunnel source address and after udp_set_kernel_tunneling() starts
receiving of all UDP packets destined to 4754 port. Each kernel socket
maintains list of tunnels with different destination addresses. Thus
when several tunnels use the same source address, they all handled by
single socket. The IP[V6]_BINDANY socket option is used to be able bind
socket to source address even if it is not yet available in the system.
This may happen on system boot, when gre(4) interface is created before
source address become available. The encapsulation and sending of packets
is done directly from gre(4) into ip[6]_output() without using sockets.
Reviewed by: eugen
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D19921
This commit adds new if_alloc_domain() and if_alloc_dev() methods to
allocate ifnets. When called with a domain on a NUMA machine,
ifalloc_domain() will record the NUMA domain in the ifnet, and it will
allocate the ifnet struct from memory which is local to that NUMA
node. Similarly, if_alloc_dev() is a wrapper for if_alloc_domain
which uses a driver supplied device_t to call ifalloc_domain() with
the appropriate domain.
Note that the new if_numa_domain field fits in an alignment pad in
struct ifnet, and so does not alter the size of the structure.
Reviewed by: glebius, kib, markj
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D19930
r345708 worked for the base system, but unfortunately, caused a lot of
disruption for third-party packages that relied on C++, since bsd.sys.mk is
used by applications outside the base system. The defaults picked didn't match
the compiler's defaults and broke some builds that didn't specify a standard,
as well as some that overrode the value by setting `-std=gnu++14` (for
example) manually.
This change takes a more relaxed approach to appending `-std=${CXXSTD}` to
CXXFLAGS, by only doing so when the value is specified, as opposed to
overriding the standard set by an end-user. This avoids the need for having
to bake NOP default into bsd.sys.mk for supported compiler-toolchain
versions.
In order to make this change possible, add CXXSTD to Makefile snippets which
relied on the default value (c++11) added in r345708.
MFC after: 2 weeks
MFC with: r345708, r346574
Reviewed by: emaste
Reported by: jbeich
Differential Revision: https://reviews.freebsd.org/D19895 (as part of a larger change)
Previous spellings of my name (NGie, Ngie) weren't my legal spelling. Use Enji
instead for clarity.
While here, remove "All Rights Reserved" from copyrights I "own".
MFC after: 1 week
This fixes a bug where, even when hw.psm.tap_enabled=0, touchpad taps
were processed.
tap_enabled has three states: unconfigured, disabled, and enabled (-1, 0, 1).
To respect PR kern/139272, taps are ignored only when explicity disabled.
Submitted by: Ben LeMasurier <ben@crypt.ly> (initial version)
MFC after: 2 weeks
It is a useful arc4random wrapper in the kernel for much the same reasons as
in userspace. Move the source to libkern (because kernel build is
restricted to sys/, but userspace can include any file it likes) and build
kernel and libc versions from the same source file.
Copy the documentation from arc4random_uniform(3) to the section 9 page.
While here, add missing arc4random_buf(9) symlink.
Sponsored by: Dell EMC Isilon
FreeBSD does not set the pid field in the pfloghdr struct. This field is
populated on other platforms, document this to save people from trying
to use this field.
Event: Aberdeen hackathon 2019
Reviewed by: kp, bcr, bz
Approved by: bz (mentor)
Differential Revision: https://reviews.freebsd.org/D19952
FDT_DTS_FILE was built separately with a rule in sys/conf/files and
recreated the rules we used in dtb.mk. Now that we have other infrastructure
to build a DTB along with the kernel, fold FDT_DTS_FILE into that since it
doesn't have any special requirements.
fdt(4) never got revised to mention the DTS/DTSO make options, so do that
now.
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D19736
isc_rxd_refill, isc_rxd_flush return nothing, not void *.
isc_txd_credits_update, isc_rxd_available return int, not int *.
isc_txd_credits_update has a bool as final argument, not a uint32_t.
Prior to r315217 it took four arguments; the final two were
uint32_t, bool.
Reported by: Gerald Aryeetey <aryeeteygerald_rogers.com>
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
The imagined use is for early boot consumers of random to be able to make
decisions based on whether random is available yet or not. One such
consumer seems to be __stack_chk_init(), which runs immediately after random
is initialized. A follow-up patch will attempt to address that.
Reported by: many
Reviewed by: delphij (except man page)
Approved by: secteam(delphij)
Differential Revision: https://reviews.freebsd.org/D19926
The pflog0 interface is created when the module is loaded, this can
be triggered by pf and pflogd being enabled or by kldloading the module.
By default the interface would be pflog0, add the ifconfig stage of the
example to make this example clearer.
Reviewed by: kp, bz, bcr, jtl, 0mp
Approved by: jtl (mentor), bz (mentor)
Differential Revision: https://reviews.freebsd.org/D19861
read_random() is/was used, mostly without error checking, in a lot of
very sensitive places in the kernel -- including seeding the widely used
arc4random(9).
Most uses, especially arc4random(9), should block until the device is seeded
rather than proceeding with a bogus or empty seed. I did not spy any
obvious kernel consumers where blocking would be inappropriate (in the
sense that lack of entropy would be ok -- I did not investigate locking
angle thoroughly). In many instances, arc4random_buf(9) or that family
of APIs would be more appropriate anyway; that work was done in r345865.
A minor cleanup was made to the implementation of the READ_RANDOM function:
instead of using a variable-length array on the stack to temporarily store
all full random blocks sufficient to satisfy the requested 'len', only store
a single block on the stack. This has some benefit in terms of reducing
stack usage, reducing memcpy overhead and reducing devrandom output leakage
via the stack. Additionally, the stack block is now safely zeroed if it was
used.
One caveat of this change is that the kern.arandom sysctl no longer returns
zero bytes immediately if the random device is not seeded. This means that
FreeBSD-specific userspace applications which attempted to handle an
unseeded random device may be broken by this change. If such behavior is
needed, it can be replaced by the more portable getrandom(2) GRND_NONBLOCK
option.
On any typical FreeBSD system, entropy is persisted on read/write media and
used to seed the random device very early in boot, and blocking is never a
problem.
This change primarily impacts the behavior of /dev/random on embedded
systems with read-only media that do not configure "nodevice random". We
toggle the default from 'charge on blindly with no entropy' to 'block
indefinitely.' This default is safer, but may cause frustration. Embedded
system designers using FreeBSD have several options. The most obvious is to
plan to have a small writable NVRAM or NAND to persist entropy, like larger
systems. Early entropy can be fed from any loader, or by writing directly
to /dev/random during boot. Some embedded SoCs now provide a fast hardware
entropy source; this would also work for quickly seeding Fortuna. A 3rd
option would be creating an embedded-specific, more simplistic random
module, like that designed by DJB in [1] (this design still requires a small
rewritable media for forward secrecy). Finally, the least preferred option
might be "nodevice random", although I plan to remove this in a subsequent
revision.
To help developers emulate the behavior of these embedded systems on
ordinary workstations, the tunable kern.random.block_seeded_status was
added. When set to 1, it blocks the random device.
I attempted to document this change in random.4 and random.9 and ran into a
bunch of out-of-date or irrelevant or inaccurate content and ended up
rototilling those documents more than I intended to. Sorry. I think
they're in a better state now.
PR: 230875
Reviewed by: delphij, markm (earlier version)
Approved by: secteam(delphij), devrandom(markm)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D19744
Since r233109, kldload has the -n option, which silently ignores options
that are already loaded.
https://lists.freebsd.org/pipermail/freebsd-rc/2018-December/003899.html
Note that this script no longer reports if the module is already loaded,
but it could be argued this wasn't particularly useful information.
PR: docs/234248
Reviewed by: bcr (docs), kib, rgrimes (visual)
Approved by: jilles
Differential Revision: https://reviews.freebsd.org/D18670
- Remove issues that no longer apply thanks to devfs
- Add language pointing out devfs's role and referencing its config
- Add a "historical notes" section and move discussion of block vs character devs to it, including pointing out the removal of block devs
- Modernize some examples
MFC after: 1 week
PR: 236970
Submitted by: andrew@tao173.riddles.org.uk
Reviewed by: 0mp
Differential Revision: https://reviews.freebsd.org/D19799
The current approach of injecting manifest into mac_veriexec is to
verify the integrity of it in userspace (veriexec (8)) and pass its
entries into kernel using a char device (/dev/veriexec).
This requires verifying root partition integrity in loader,
for example by using memory disk and checking its hash.
Otherwise if rootfs is compromised an attacker could inject their own data.
This patch introduces an option to parse manifest in kernel based on envs.
The loader sets manifest path and digest.
EVENTHANDLER is used to launch the module right after the rootfs is mounted.
It has to be done this way, since one might want to verify integrity of the init file.
This means that manifest is required to be present on the root partition.
Note that the envs have to be set right before boot to make sure that no one can spoof them.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Reviewed by: sjg
Obtained from: Semihalf
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D19281
This is particularly useful when installing programs for tests that need to be
linked statically, e.g., mini-me from capsicum-test, which is linked statically
to avoid the dynamic library lookup in the upstream project.
Reviewed by: emaste
Approved by: emaste (mentor)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D19756
The behavior prior to this change would not override default values if set in
`bsd.own.mk`, or (in the more general case) globally before `bsd.progs.mk` was
included. This affected `bsd.test.mk` as well, since it consumes
`bsd.progs.mk`.
Some examples of this failing behavior are as follows:
* `BINMODE` defaults to 0555 per `bsd.own.mk`. If someone wanted to set the
`BINMODE` to `NOBINMODE` (0444) for `prog`, for example, like
`BINMODE.prog= ${NOBINMODE}`, `bsd.progs.mk` would not honor the per-PROG
setting.
* An application, `prog`, does not build at `WARNS?= 6`. Before this change,
setting to a lower `WARNS` value, e.g., `WARNS.prog= 3`, would have been
impossible, requiring that `prog` be built from another directory,
the global `WARNS` be lowered, or a per-PROG value needing to be set
across the board. None of the above workarounds is desirable.
This change unbreaks variables defined in `PROG_OVERRIDE_VARS` which have
defaults set before `bsd.progs.mk` is included, by setting them to their
defined values if set on a per-PROG basis.
Reviewed by: asomers
Approved by: emaste (mentor)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D19755
The current logic for CSTD/CXXSTD requires homogenity as far as the
supported C/C++ standards, which is a sensible default. However, when
dealing with differing versions of C++, some code may compile with C++11, but
not C++17 (for instance). So in order to avoid having people convert over their
code to the new standard, give the users the ability to specify the standard on
a per-program basis.
This will allow a user to override the supporting standard for a set of
programs, mixing C++11 with C++14 (for instance).
Reviewed by: asomers
Apprved by: emaste (mentor)
MFC after: 1 month
MFC with: r345708
Differential Revision: https://reviews.freebsd.org/D19738
CXXSTD was added as the C++ analogue to CSTD.
CXXSTD defaults to `-std=c++11` with supporting compilers; `-std=gnu++98`,
otherwise for older versions of g++.
This change standardizes the CXXSTD variable, originally added to
googletest.test.inc.mk as part of r345203.
As part of this effort, convert all `CXXFLAGS+= -std=*` calls to use `CXXSTD`.
Notes:
This value is not sanity checked in bsd.sys.mk, however, given the two
most used C++ compilers on FreeBSD (clang++ and g++) support both modes, it is
likely to work with both toolchains. This method will be refined in the future
to support more variants of C++, as not all versions of clang++ and g++ (for
instance) support C++14, C++17, etc.
Any manual appending of `-std=*` to `CXXFLAGS` should be replaced with CXXSTD.
Example:
Before this commit:
```
CXXFLAGS+= -std=c++14
```
After this commit:
```
CXXSTD= c++14
```
Reviewed by: asomers
Approved by: emaste (mentor)
MFC after: 1 month
MFC with: r345203, r345704, r345705
Relnotes: yes
Tested with: make tinderbox
Differential Revision: https://reviews.freebsd.org/D19732
When a review is closed via Phabricator it updates the patch attached to the
review. I downloaded the raw patch from Phabricator, applied it, and repeated
my mistake from r345704 by accident mixing content from D19732 and D19738.
For my own personal sanity, I will try not to mix reviews like this in the
future.
MFC after: 1 month
MFC with: r345706
Approved by: emaste (mentor, implicit)
CXXSTD was added as the C++ analogue to CSTD.
CXXSTD defaults to `-std=c++11` with supporting compilers; `-std=gnu++98`,
otherwise for older versions of g++.
This change standardizes the CXXSTD variable, originally added to
googletest.test.inc.mk as part of r345203.
As part of this effort, convert all `CXXFLAGS+= -std=*` calls to use `CXXSTD`.
Notes:
This value is not sanity checked in bsd.sys.mk, however, given the two
most used C++ compilers on FreeBSD (clang++ and g++) support both modes, it is
likely to work with both toolchains. This method will be refined in the future
to support more variants of C++, as not all versions of clang++ and g++ (for
instance) support C++14, C++17, etc.
Any manual appending of `-std=*` to `CXXFLAGS` should be replaced with CXXSTD.
Example:
Before this commit:
```
CXXFLAGS+= -std=c++14
```
After this commit:
```
CXXSTD= c++14
```
Reviewed by: asomers
Approved by: emaste (mentor)
MFC after: 1 month
MFC with: r345203, r345704, r345705
Relnotes: yes
Tested with: make tinderbox
Differential Revision: https://reviews.freebsd.org/D19732
I accidentally committed code from two reviews. I will reintroduce the code to
bsd.progs.mk as part of a separate commit from r345704.
Approved by: emaste (mentor, implicit)
MFC after: 2 months
MFC with: r345704
CXXSTD defaults to `-std=c++11` with supporting compilers; `-std=gnu++98`,
otherwise for older versions of g++.
This change standardizes the CXXSTD variable, originally added to
googletest.test.inc.mk as part of r345203.
As part of this effort, convert all `CXXFLAGS+= -std=*` calls to use `CXXSTD`.
Notes:
This value is not sanity checked in bsd.sys.mk, however, given the two
most used C++ compilers on FreeBSD (clang++ and g++) support both modes, it is
likely to work with both toolchains. This method will be refined in the future
to support more variants of C++, as not all versions of clang++ and g++ (for
instance) support C++14, C++17, etc.
Any manual appending of `-std=*` to `CXXFLAGS` should be replaced with CXXSTD.
Example:
Before this commit:
```
CXXFLAGS+= -std=c++14
```
After this commit:
```
CXXSTD= c++14
```
Reviewed by: asomers
Approved by: emaste (mentor)
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D19732
This makes it easier for googletest users to leverage googletest, instead of
forcing them to plug GTEST_CXXFLAGS into CXXFLAGS manually (resulting in
unnecessary duplication).
I will be following this up with a more proper fix in src.libnames.mk, as
src.libnames.mk should be automatically adding this directory to
CFLAGS/CXXFLAGS when private libraries are referenced. Not doing so can result
in mismatches between base-provided private library's and ports-provided
library's headers.
While here, tweak the comment to clarify what the intent is behind spamming
CXXFLAGS.
MFC after: 5 weeks
MFC with: r345203
Reported by: asomers
Reviewed by: asomers
Approved by: emaste (mentor)
Differential Revision: https://reviews.freebsd.org/D19731
This was missed in r342139 when timed(8) was removed and fixes a
warning when running makeman to regenerate src.conf.5.
Differential Revision: https://reviews.freebsd.org/D19486
modules by declaring corresponding variables in rc.conf. Also document
them in rc.conf(5).
Submitted by: Dries Michiels
Differential Revision: https://reviews.freebsd.org/D19673
From Jake:
The iflib core never modifies the isc_driver_version string. Allow
drivers to safely assign pointers to constant buffers by marking this
parameter const.
Submitted by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed by: erj@, gallatin@, jhb@
MFC after: 1 week
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D19577
* Set MK_OPENMP to yes by default only on amd64, for now.
* Bump __FreeBSD_version to signal this addition.
* Ensure gcc's conflicting omp.h is not installed if MK_OPENMP is yes.
* Update OptionalObsoleteFiles.inc to cope with the conflicting omp.h.
* Regenerate src.conf(5) with new WITH/WITHOUT fragments.
Relnotes: yes
PR: 236062
MFC after: 1 month
X-MFC-With: r344779
Looks like the example was broken by change of SYSCTL_STATIC_CHILDREN
definition in r267992. Fix build by switching to using SYSCTL_ADD_ROOT_NODE
PR: 236139
Submitted by: Andrew Reiter <arr@watson.org>
MFC after: 1 week
This initial integration takes googlemock/googletest release 1.8.1, integrates
the library, tests, and sample unit tests into the build.
googlemock/googletest's inclusion is optionally available via `MK_GOOGLETEST`.
`MK_GOOGLETEST` is dependent on `MK_TESTS` and is enabled by default when
built with a C++11 capable toolchain.
Google tests can be specified via the `GTESTS` variable, which, in comparison
with the other test drivers, is more simplified/streamlined, as Googletest only
supports C++ tests; not raw C or shell tests (C tests can be written in C++
using the standard embedding methods).
No dependent libraries are assumed for the tests. One must specify `gmock`,
`gmock_main`, `gtest`, or `gtest_main`, via `LIBADD` for the program.
More information about googlemock and googletest can be found on the
Googletest [project page](https://github.com/google/googletest), and the
[GoogleMock](https://github.com/google/googletest/blob/v1.8.x/googlemock/docs/Documentation.md)
and
[GoogleTest](https://github.com/google/googletest/tree/v1.8.x/googletest/docs)
docs.
These tests are originally integrated into the build as plain driver tests, but
will be natively integrated into Kyua in a later version.
Known issues/Errata:
* [WhenDynamicCastToTest.AmbiguousCast fails on FreeBSD](https://github.com/google/googletest/issues/2172)
Reviewed by: asomers
Approved by: emaste (mentor)
MFC after: 2 months
Differential Revision: https://reviews.freebsd.org/D19551
while using LSI RAID adapters as it was completely obscure before:
mfi has no TRIM support at all and mrsas provides TRIM
if underlying adapter does it (for Non-RAID drives generally).
FreeBSD removed the default /etc/pf.conf file in previous releases, but
the documentation kept mentioning it like any other file present in the
system. Change pf.conf(5) to mention in the description of the default
ruleset location that this file needs to be created manually. Also, the
default rc.conf file had it's comment extended a bit to let people know
that this file does not exist by default.
PR: 231977
Submitted by: koobs@
Reviewed by: kp@, 0mp@
Approved by: kp@
MFC after: 10 days
Differential Revision: https://reviews.freebsd.org/D19530
At the moment the manual page is not documenting how to build
a flavored package. Let's start documenting flavors with
an example of a typical use case.
Reported by: cem, dim
Reviewed by: bcr, cem, mat, matthew
Approved by: cem (src)
Differential Revision: https://reviews.freebsd.org/D19531
- Alignment issues:
* Add missing __packed attributes + padding across all drivers; in
most places there was an assumption that padding will be always
minimally suitable; in few places - e.g., in urtw(4) / rtwn(4) -
padding was just missing.
* Add __aligned(8) attribute for all Rx radiotap headers since they can
contain 64-bit TSF timestamp; it cannot appear in Tx radiotap headers, so
just drop the attribute here. Refresh ieee80211_radiotap(9) man page
accordingly.
- Since net80211 automatically updates channel frequency / flags in
ieee80211_radiotap_chan_change() drop duplicate setup for these fields
in drivers.
Tested with Netgear WG111 v3 (urtw(4)), STA mode.
MFC after: 2 weeks
Update the members of the doceng team to include ryusuke@ and me.
Sort and reduce number of line breaks so that our bubble in the
chart is a bit more compact (similar to portmgr next to it).
Reminded by: gjb
This permits legacy GDB to still be built and installed if
WITHOUT_BINUTILS is set (e.g. if base/binutils is installed).
Reviewed by: emaste
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D19480
With the last core election, matthew@ stepped down and handed over to jrm@ to
serve as new core secretary. Update this file to match.
Approved by: core (implicit)
UEFI related headers were copied from edk2.
A new build option "MK_LOADER_EFI_SECUREBOOT" was added to allow
loading of trusted anchors from UEFI.
Certificate revocation support is also introduced.
The forbidden certificates are loaded from dbx variable.
Verification fails in two cases:
There is a direct match between cert in dbx and the one in the chain.
The CA used to sign the chain is found in dbx.
One can also insert a hash of TBS section of a certificate into dbx.
In this case verifications fails only if a direct match with a
certificate in chain is found.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Reviewed by: sjg
Obtained from: Semihalf
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D19093
FDT data. The sector size must be a multiple of the device's page size.
If not configured, use the historical default of the device page size.
Setting the disk sector size to 512 or 4096 allows a variety of standard
filesystems to be used on the device. Of course you wouldn't want to be
writing frequently to a SPI flash chip like it was a disk drive, but for
data that gets written once (or rarely) and read often, using a standard
filesystem is a nice convenient thing.
@cem removed references to pdwait4(2) (a nonexistent syscall) in
r320058.
This change removes references to pdwait4(2) and `CAP_PDWAIT` in
rights(4) to not mislead the user into thinking that pdwait4(2)/`CAP_PDWAIT` is
actually implemented in the stock FreeBSD kernel.
The goal of this functionality was to simplify monitoring/manipulating
processes started with `pdfork`, et al, and avoid races with waiting on pids.
The syscall was never completed though--just discussed on the capsicum mailing
list back in 2015:
https://lists.cam.ac.uk/pipermail/cl-capsicum-discuss/2015-May/msg00012.html
. That being said, there are members of the project (@rwatson, etc) who
have longterm goals to implement this syscall to better secure pdfork(2)
calls.
PR: 235871
Reviewed by: emaste
Discussed with: rwatson
Approved by: emaste (mentor)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D18950
There are some problem reports possibly related to the new driver use of
multiple interrupts on older cards. Hopefully this allow to workaround
them.
MFC after: 1 week
Sponsored by: iXsystems, Inc.
Embedded lzma decompression library becomes a module usable by other
consumers, in addition to geom_uzip.
Most important code changes are
- removal of XZ_DEC_SINGLE define, we need the code to work
with XZ_DEC_DYNALLOC;
- xz_crc32_init() call is removed from geom_uzip, xz module handles
initialization on its own.
xz is no longer embedded into geom_uzip, instead the depend line for
the module is provided, and corresponding kernel option is added to
each MIPS kernel config file using geom_uzip.
The commit also carries unrelated cleanup by removing excess "device geom_uzip"
in places which were missed in r344479.
Reviewed by: cem, hselasky, ray, slavash (previous versions)
Sponsored by: Mellanox Technologies
Differential revision: https://reviews.freebsd.org/D19266
MFC after: 3 weeks
Instead of PRIVATELIB + NO_PIC. This avoids the need for the wlandebug
PIE special case added in r344211, and provides a stronger guarantee
against 3rd party software coming to depend on the API or ABI.
If / when we declare the API/ABI to be stable we can make it a normal
library.
Discussed with: bapt
Sponsored by: The FreeBSD Foundation
Update the diff to include other missing sysctl types found in sysctl.h.
Some of these sysctls are already documented in other pages (e.g counter(9)
and ZONE(9)), but they should at least be mentioned here for completeness.
This patch now documents all of the following:
- SYSCTL_BOOL/SYSCTL_ADD_BOOL
- SYSCTL_COUNTER_U64/SYSCTL_ADD_COUNTER_U64
- SYSCTL_COUNTER_U64_ARRAY/SYSCTL_ADD_COUNTER_U64_ARRAY
- SYSCTL_SBINTIME_MSEC/SYSCTL_ADD_SBINTIME_MSEC
- SYSCTL_SBINTIME_USEC/SYSCTL_ADD_SBINTIME_USEC
- SYSCTL_UMA_CUR/SYSCTL_ADD_UMA_CUR
- SYSCTL_UMA_MAX/SYSCTL_ADD_UMA_MAX
Submitted by: mhorne063_gmail.com
Reviewed by: bcr, hselasky
Approved by: bcr (doc), hselasky (src)
Approved by: krion (mentor, implicit), mat (mentor, implicit)
Differential Revision: https://reviews.freebsd.org/D19272
for struct ip_mreq remains in place.
The struct ip_mreqn is Linux extension to classic BSD multicast API. It
has extra field allowing to specify the interface index explicitly. In
Linux it used as argument for IP_MULTICAST_IF and IP_ADD_MEMBERSHIP.
FreeBSD kernel also declares this structure and supports it as argument
to IP_MULTICAST_IF since r170613. So, we have structure declared but
not fully supported, this confused third party application configure
scripts.
Code handling IP_ADD_MEMBERSHIP was mixed together with code for
IP_ADD_SOURCE_MEMBERSHIP. Bringing legacy and new structure support
into the mess would made the "argument switcharoo" intolerable, so
code was separated into its own switch case clause.
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D19276
Add or fix options to control static and dynamic configuration. Keep
the default of scteken, but default to statically configuring all available
emulators (now 3 instead of 1).
The dumb emulator is almost usable. libedit and libreadline handle
dumb terminals perfectly for at least shell history. less(1) works
as well as possible except on exit. But curses programs make messes.
The dumb emulator has strange color support, with 2 dumb colors for
normal output but fancy colorization for the cursor, mouse pointer and
(with a non-dumb initial emulator) for low-level console output.
Using the sc emulator instead of the default of scteken fixes at least
the following bugs:
- NUL is a printing character in cons25 but not in teken
- teken doesn't support fixed colors for "reverse" video.
- The best versions of sc are about 10 times faster than scteken (for
printing to the frame buffer). This version is only about 5 times
faster.
Fix configuration features:
- make SC_DFLT_TERM (for setting the initial emulator) a normal option.
Add configuration features:
- negative options SC_NO_TERM_* for omitting emulators in the static config.
Modules for emulators might work, but I don't know of any
- vidcontrol -e shows the available emulators
- vidcontrol -E <emulator> sets the active emulator.
The move to /usr/include/private prefixed paths seems to require a bit more
effort in order to compile programs.
Install the headers to /usr/include/private/g{mock,test}/... and automatically
include /usr/include/private in GTESTS_CXXFLAGS to make compilation seamless. I
will work on the more global problem later with @bdrewery.
A previous iteration referenced/used googletest.test.flags.mk, not
googletest.test.inc.mk. The latter name is what I settled on as this
Makefile snippet can include more logic than flags.
Long story short, some of the tests were failing because they expected either
dynamic_cast or RTTI to be functional and it wasn't.
Move all common CXXFLAGS out to googletest.test.inc.mk and reference it from
googletest.test.mk and .../googletest/Makefile.inc
googletest.test.mk is a rudimentary wrapper around the plain test interface
(for now), which only supports C++ programs, specified by the `GTESTS`
variable.
In the future, kyua will support gtests in a more native manner.
These libraries don't compile on non-C++-11 capable compilers, e.g., g++ 4.2.1
and its corresponding implementation of the c++ library, i.e., libstdc++.
Blacklist compilation on all non-C++-11 capable compilers and give others the
option of opting out of building/installing gmock/gtest via MK_GOOGLETEST.
This option is controlled by MK_CXX and MK_TESTS, as ATF compilation is.
Building binaries as PIE allows the executable itself to be loaded at a
random address when ASLR is enabled (not just its shared libraries).
With this change PIE objects have a .pieo extension and INTERNALLIB
libraries libXXX_pie.a.
MK_PIE is disabled for some kerberos5 tools, Clang, and Subversion, as
they explicitly reference .a libraries in their Makefiles. These can
be addressed on an individual basis later. MK_PIE is also disabled for
rtld-elf because it is already position-independent using bespoke
Makefile rules.
Currently only dynamically linked binaries will be built as PIE.
Discussed with: dim
Reviewed by: kib
MFC after: 1 month
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D18423
This issue was noticed when running `make manlint` as part of MFCing r342597 to
^/stable/11:
```
$ make -C share/man/man8 rc.8lint
mandoc -Tascii -Tlint rc.8
mandoc: rc.8:548:6: STYLE: referenced manual not found: Xr rc.resume 8
$
```
This is a followup commit to r339818.
Reviewed by: eugen
Approved by: jtl (mentor)
MFC after: 1 week
MFC to: ^/stable/12
Differential Revision: https://reviews.freebsd.org/D19158
The MPC8540 is actually e500v1, which doesn't have double-precision floating
point support. The 8548 does, so use that as the CPU target.
MFC after: 2 weeks
The logic I introduced in r322511 unfortunately left chflags schg'ed
directories behind created by `make hier` (in the stock /etc/mtree
files, this is limited to /var/empty).
The proposed change calls `chflags -R 0` and `rm -Rf ...` to clean all
of the directories that could not be removed by `${MAKE} clean`.
`${MAKE} clean` in bsd.obj.mk calls `cleandir`/`cleanobj`, which handles
the first directory tree walk/removal.
Approved by: emaste (mentor)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D18641
Use recent best practices for Copyright form at the top of
the license:
1. Remove all the All Rights Reserved clauses on our stuff. Where we
piggybacked others, use a separate line to make things clear.
2. Use "Netflix, Inc." everywhere.
3. Use a single line for the copyright for grep friendliness.
4. Use date ranges in all places for our stuff.
Approved by: Netflix Legal (who gave me the form), adrian@ (pmc files)
The KPI have been reviewed and cleansed of features that were planned
back 20 years ago and never implemented. The pfil(9) internals have
been made opaque to protocols with only returned types and function
declarations exposed. The KPI is made more strict, but at the same time
more extensible, as kernel uses same command structures that userland
ioctl uses.
In nutshell [KA]PI is about declaring filtering points, declaring
filters and linking and unlinking them together.
New [KA]PI makes it possible to reconfigure pfil(9) configuration:
change order of hooks, rehook filter from one filtering point to a
different one, disconnect a hook on output leaving it on input only,
prepend/append a filter to existing list of filters.
Now it possible for a single packet filter to provide multiple rulesets
that may be linked to different points. Think of per-interface ACLs in
Cisco or Juniper. None of existing packet filters yet support that,
however limited usage is already possible, e.g. default ruleset can
be moved to single interface, as soon as interface would pride their
filtering points.
Another future feature is possiblity to create pfil heads, that provide
not an mbuf pointer but just a memory pointer with length. That would
allow filtering at very early stages of a packet lifecycle, e.g. when
packet has just been received by a NIC and no mbuf was yet allocated.
Differential Revision: https://reviews.freebsd.org/D18951
iflib is already a module, but it is unconditionally compiled into the
kernel. There are drivers which do not need iflib(4), and there are
situations where somebody might not want iflib in kernel because of
using the corresponding driver as module.
Reviewed by: marius
Discussed with: erj
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D19041
