AKA Make time_t 64 bits on powerpc(32).
PowerPC currently (until now) was one of two architectures with a 32-bit time_t
on 32-bit archs (the other being i386). This is an ABI breakage, so all ports,
and all local binaries, *must* be recompiled.
Tested by: andreast, others
MFC after: Never
Relnotes: Yes
Our current approach to dependency tracking cannot cope with switching
generated asm syscall stubs into C wrappers. Perpetuate the hack in
Makefile.inc1 to paper over the problem until we can take a holistic
approach to fixing dependency problems.
Differential Revision: https://reviews.freebsd.org/D11344
Add forward compatibility so that new binaries can run on old
kernels. If the new system call from ino64 isn't available on your
system, then the old one will be used and the results translated. The
stat and statfs families of functions are fully emulated. While not
required by policy, in this case it is helpful to our users to provide
this compatibility. In this case, it allows rollback of the kernel
after installing a new userland should a problem be discovered. It
also prevents foot-shooting if a user does an install before rebooting
with the new kernel. Finally, it allows the use case where one needs
to run new binaries on an old kernel as part of an upgrade process.
The getdirentries family uses tricks that may not work on remote
filesystems. Specifically, it uses a buffer 1/4 the size requested to
get the data from he old syscall.
The code carefully uses direct syscalls for old system calls to avoid
referencing freebsd11_* symbols, which contaminate ld-elf.so.1's
export table due to its use of stat functions, which causes errno to
be incorrect in client programs due to the wrong *stat* function being
resolved in some cases.
This code should removed sometime after 12 is branched.
Tested on: 12-current binaries on a 10.3-beta kernel run and return
consistent results. 12-current kernel and userland with
packages from before ino64 was committed also work.
Differential Revision: https://reviews.freebsd.org/D11185
Reviewed by: kib@, emaste@
The BSDL dtc has grown the needed features (overlays mostly) and is able to
compile all of our base DTS.
You can use WITH_GPL_DTC is you need the GPL one or DTC= in make.conf(5)
to specify an alternate location for the compiler to use.
Discussed with: emaste, imp
All manpages in base are now compatible with mandoc(1), all roff documentation
will be relocated in the doc tree. man(1) can now use groff from the ports tree
if it needs.
Also remove checknr(1) and colcrt(1) which are only useful with groff.
Approved by: (no objections on the mailing lists)
META_MODE users actually do not need to do anything special assuming
they have COMPAT_FREEBSD11 enabled. The host tools in WORLDTMP will
continue to work just fine.
- mention COMPAT_FREEBSD11 earlier so that the steps are in chronological
order
- suggest removing /usr/obj before build to ensure there are no stale
objects
Reviewed by: allanjude, kib
Sponsored by: The FreeBSD Foundation
The upgrade process requires COMPAT_FREEBSD11 to support the combination
of "old" userland and "new" kernel that exists after "make kernel" and
reboot. Mention this explicitly for those using custom kernel configs.
Once the "new" world is installed the COMPAT_FREEBSD11 could be removed
again, but that does not seem necessary to mention in UPDATING.
Reported by: kib
Sponsored by: The FreeBSD Foundation
The existing upgrade process documented in UPDATING is both necessary
and sufficient for upgrading across the ino64 change. However, the
shortcut of installing both kernel + world before a single reboot has
been possible for quite some time, and several developers and users
were surprised by fallout from ino64. Add an explicit entry pointing
out that the full process must be followed.
Reviewed by: allanjude, gjb, vangyzen
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D10877
r279908 added logic to Makefile.inc1 to automatically set
CROSS_BINUTILS_PREFIX for architectures not supported by the in-tree
binutils: arm64 when first introduced, and later riscv64 as well.
LLVM's LLD linker is now included in the base system, and is enabled by
default for arm64 and capable of linking world and kernel. Thus, avoid
automatically setting CROSS_BINUTILS_PREFIX and requiring the binutils
port if WITH_LLD_IS_LD is true.
Reviewed by: kan
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D10310
If a jail has an explicitly assigned IPv6 loopback address then allow it
to be used instead of remapping requests for the loopback adddress to the
first IPv6 address assigned to the jail.
This fixes issues where applications attempt to detect their bound port
where they requested a loopback address, which was available, but instead
the kernel remapped it to the jails first address.
This is the same fix applied to IPv4 fix by: r316313
Also:
* Correct the description of prison_check_ip6_locked to match the code.
MFC after: 2 weeks
Relnotes: Yes
Sponsored by: Multiplay
If a jail has an explicitly assigned loopback address then allow it to be
used instead of remapping requests for the loopback adddress to the first
IPv4 address assigned to the jail.
This fixes issues where applications attempt to detect their bound port
where they requested a loopback address, which was available, but instead
the kernel remapped it to the jails first address.
A example of this is binding nginx to 127.0.0.1 and then running "service
nginx upgrade" which before this change would cause nginx to fail.
Also:
* Correct the description of prison_check_ip4_locked to match the code.
MFC after: 2 weeks
Relnotes: Yes
Sponsored by: Multiplay
the default partition, eMMC v4.41 and later devices can additionally
provide up to:
1 enhanced user data area partition
2 boot partitions
1 RPMB (Replay Protected Memory Block) partition
4 general purpose partitions (optionally with a enhanced or extended
attribute)
Of these "partitions", only the enhanced user data area one actually
slices the user data area partition and, thus, gets handled with the
help of geom_flashmap(4). The other types of partitions have address
space independent from the default partition and need to be switched
to via CMD6 (SWITCH), i. e. constitute a set of additional "disks".
The second kind of these "partitions" doesn't fit that well into the
design of mmc(4) and mmcsd(4). I've decided to let mmcsd(4) hook all
of these "partitions" up as disk(9)'s (except for the RPMB partition
as it didn't seem to make much sense to be able to put a file-system
there and may require authentication; therefore, RPMB partitions are
solely accessible via the newly added IOCTL interface currently; see
also below). This approach for one resulted in cleaner code. Second,
it retains the notion of mmcsd(4) children corresponding to a single
physical device each. With the addition of some layering violations,
it also would have been possible for mmc(4) to add separate mmcsd(4)
instances with one disk each for all of these "partitions", however.
Still, both mmc(4) and mmcsd(4) share some common code now e. g. for
issuing CMD6, which has been factored out into mmc_subr.c.
Besides simply subdividing eMMC devices, some Intel NUCs having UEFI
code in the boot partitions etc., another use case for the partition
support is the activation of pseudo-SLC mode, which manufacturers of
eMMC chips typically associate with the enhanced user data area and/
or the enhanced attribute of general purpose partitions.
CAVEAT EMPTOR: Partitioning eMMC devices is a one-time operation.
- Now that properly issuing CMD6 is crucial (so data isn't written to
the wrong partition for example), make a step into the direction of
correctly handling the timeout for these commands in the MMC layer.
Also, do a SEND_STATUS when CMD6 is invoked with an R1B response as
recommended by relevant specifications. However, quite some work is
left to be done in this regard; all other R1B-type commands done by
the MMC layer also should be followed by a SEND_STATUS (CMD13), the
erase timeout calculations/handling as documented in specifications
are entirely ignored so far, the MMC layer doesn't provide timeouts
applicable up to the bridge drivers and at least sdhci(4) currently
is hardcoding 1 s as timeout for all command types unconditionally.
Let alone already available return codes often not being checked in
the MMC layer ...
- Add an IOCTL interface to mmcsd(4); this is sufficiently compatible
with Linux so that the GNU mmc-utils can be ported to and used with
FreeBSD (note that due to the remaining deficiencies outlined above
SANITIZE operations issued by/with `mmc` currently most likely will
fail). These latter will be added to ports as sysutils/mmc-utils in
a bit. Among others, the `mmc` tool of the GNU mmc-utils allows for
partitioning eMMC devices (tested working).
- For devices following the eMMC specification v4.41 or later, year 0
is 2013 rather than 1997; so correct this for assembling the device
ID string properly.
- Let mmcsd.ko depend on mmc.ko. Additionally, bump MMC_VERSION as at
least for some of the above a matching pair is required.
- In the ACPI front-end of sdhci(4) describe the Intel eMMC and SDXC
controllers as such in order to match the PCI one.
Additionally, in the entry for the 80860F14 SDXC controller remove
the eMMC-only SDHCI_QUIRK_INTEL_POWER_UP_RESET.
OKed by: imp
Submitted by: ian (mmc_switch_status() implementation)
Since the state name is an optional argument, it often can conflict
with other options. To avoid ambiguity now the state name must be
prefixed with a colon.
Obtained from: Yandex LLC
MFC after: 2 week
Sponsored by: Yandex LLC
Some of the modifications from the previous summer of code has been integrated
Modification for compatibility with GNU diff output has been added
Main difference with OpenBSD:
Implement multiple GNU diff options:
* --ignore-file-name-case
* --no-ignore-file-name-case
* --normal
* --tabsize
* --strip-trailing-cr
Make diff -p compatible with GNU diff
Implement diff -l
Make diff -r compatible with GNU diff
Capsicumize diffing 2 regular files
Add a simple test suite
Approved by: AsiaBSDcon devsummit
Obtained from: OpenBSD, GSoC
Relnotes: yes
Bring back the i486 option in GENERIC by default.
The code related to i386 CPU variants configuration has received many
changes in the last years: most of the features are detected automatically,
so there are no performance penalties from keeping the 486 support enabled.
Re-instate the 486 support: while the general configuration could still be
cleaned a bit, there is no advantage in removing it.
Differential Revision: https://reviews.freebsd.org/D9879
