2023-11-06 15:36:33 +00:00
|
|
|
Release notes for FreeBSD 15.0.
|
2019-07-17 19:09:05 +00:00
|
|
|
|
|
|
|
This file describes new user-visible features, changes and updates relevant to
|
|
|
|
users of binary FreeBSD releases. Each entry should describe the change in no
|
|
|
|
more than several sentences and should reference manual pages where an
|
|
|
|
interested user can find more information. Entries should wrap after 80
|
|
|
|
columns. Each entry should begin with one or more commit IDs on one line,
|
2021-07-30 23:07:52 +00:00
|
|
|
specified as a comma separated list and/or range, followed by a colon and a
|
|
|
|
newline. Entries should be separated by a newline.
|
2019-07-17 19:09:05 +00:00
|
|
|
|
|
|
|
Changes to this file should not be MFCed.
|
|
|
|
|
2024-09-09 15:19:28 +00:00
|
|
|
e962b37bf0ff:
|
|
|
|
When running bhyve(8) guests with a boot ROM, i.e., bhyveload(8) is not
|
|
|
|
used, bhyve now assumes that the boot ROM will enable PCI BAR decoding.
|
|
|
|
This is incompatible with some boot ROMs, particularly outdated builds
|
|
|
|
of edk2-bhyve. To restore the old behavior, add
|
|
|
|
"pci.enable_bars='true'" to your bhyve configuration.
|
|
|
|
|
|
|
|
Note in particular that the uefi-edk2-bhyve package has been renamed
|
|
|
|
to edk2-bhyve.
|
|
|
|
|
|
|
|
43caa2e805c2:
|
|
|
|
amd64 bhyve(8)'s "lpc.bootrom" and "lpc.bootvars" options are
|
|
|
|
deprecated. Use the top-level "bootrom" and "bootvars" options
|
|
|
|
instead.
|
|
|
|
|
2024-06-21 07:33:18 +00:00
|
|
|
822ca3276345:
|
|
|
|
byacc was updated to 20240109.
|
|
|
|
|
|
|
|
21817992b331:
|
|
|
|
ncurses was updated to 6.5.
|
|
|
|
|
2024-06-13 01:56:20 +00:00
|
|
|
1687d77197c0:
|
|
|
|
Filesystem manual pages have been moved to section four.
|
|
|
|
Please check ports you are maintaining for crossreferences.
|
|
|
|
|
2024-05-22 12:05:57 +00:00
|
|
|
8aac90f18aef:
|
|
|
|
new MAC/do policy and mdo(1) utility which enables a user to
|
|
|
|
become another user without the requirement of setuid root.
|
|
|
|
|
2024-05-06 18:35:35 +00:00
|
|
|
7398d1ece5cf:
|
|
|
|
hw.snd.version is removed.
|
|
|
|
|
2024-05-03 21:05:57 +00:00
|
|
|
a15f7c96a276,a8089ea5aee5:
|
|
|
|
NVMe over Fabrics controller. The nvmft(4) kernel module adds
|
|
|
|
a new frontend to the CAM target layer which exports ctl(4)
|
|
|
|
LUNs as NVMe namespaces to remote hosts. The nvmfd(8) daemon
|
|
|
|
is responsible for accepting incoming connection requests and
|
|
|
|
handing off connected queue pairs to nvmft(4).
|
|
|
|
|
|
|
|
a1eda74167b5,1058c12197ab:
|
|
|
|
NVMe over Fabrics host. New commands added to nvmecontrol(8)
|
|
|
|
to establish connections to remote controllers. Once
|
|
|
|
connections are established they are handed off to the nvmf(4)
|
|
|
|
kernel module which creates nvmeX devices and exports remote
|
|
|
|
namespaces as nda(4) disks.
|
|
|
|
|
2024-04-28 19:59:17 +00:00
|
|
|
25723d66369f:
|
sound: Retire unit.*
The unit.* code is largely obsolete and imposes limits that are no
longer needed nowadays.
- Capping the maximum allowed soundcards in a given machine. By default,
the limit is 512 (snd_max_u() in unit.c), and the maximum possible is
2048 (SND_UNIT_UMAX in unit.h). It can also be tuned through the
hw.snd.maxunit loader(8) tunable. Even though these limits are large
enough that they should never cause problems, there is no need for
this limit to exist in the first place.
- Capping the available device/channel types. By default, this is 32
(snd_max_d() in unit.c). However, these types are pre-defined in
pcm/sound.h (see SND_DEV_*), so the cap is unnecessary when we know
that their number is constant.
- Capping the number of channels per-device. By default, the limit 1024
(snd_max_c() in unit.c). This is probably the most problematic of the
limits mentioned, because this limit can never be reached, as the
maximum is hard-capped at either hw.snd.maxautovchans (16 by default),
or SND_MAXHWCHAN and SND_MAXVCHANS.
These limtits are encoded in masks (see SND_U_MASK, SND_D_MASK,
SND_C_MASK in unit.h) and are used to construct a bitfield of the form
[dsp_unit, type, channel_unit] in snd_mkunit() which is assigned to
pcm_channel->unit.
This patch gets rid of everything unit.*-related and makes a slightly
different use of the "unit" field to only contain the channel unit
number. The channel type is stored in a new pcm_channel->type field, and
the DSP unit number need not be stored at all, since we can fetch it
from device_get_unit(pcm_channel->dev). This change has the effect that
we no longer need to impose caps on the number of soundcards,
device/channel types and per-device channels. As a result the code is
noticeably simplified and more readable.
Apart from the fact that the hw.snd.maxunit loader(8) tunable is also
retired as a side-effect of this patch, sound(4)'s behavior remains the
same.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D44912
2024-04-28 19:44:35 +00:00
|
|
|
As a side-effect of retiring the unit.* code in sound(4), the
|
|
|
|
hw.snd.maxunit loader(8) tunable is also retired.
|
2024-05-02 20:43:55 +00:00
|
|
|
|
|
|
|
eeb04a736cb9:
|
|
|
|
date(1) now supports nanoseconds. For example:
|
|
|
|
`date -Ins` prints "2024-04-22T12:20:28,763742224+02:00" and
|
|
|
|
`date +%N` prints "415050400".
|
|
|
|
|
2024-04-23 16:52:30 +00:00
|
|
|
6d5ce2bb6344:
|
|
|
|
The default value of the nfs_reserved_port_only rc.conf(5) setting has
|
|
|
|
changed. The FreeBSD NFS server now requires the source port of
|
|
|
|
requests to be in the privileged port range (i.e., <= 1023), which
|
|
|
|
generally requires the client to have elevated privileges on their local
|
|
|
|
system. The previous behavior can be restored by setting
|
|
|
|
nfs_reserved_port_only=NO in rc.conf.
|
|
|
|
|
2024-04-06 18:39:42 +00:00
|
|
|
aea973501b19:
|
|
|
|
ktrace(2) will now record detailed information about capability mode
|
|
|
|
violations. The kdump(1) utility has been updated to display such
|
|
|
|
information.
|
2024-04-23 16:52:30 +00:00
|
|
|
|
2024-03-12 15:24:39 +00:00
|
|
|
f32a6403d346:
|
|
|
|
One True Awk updated to 2nd Edition. See https://awk.dev for details
|
|
|
|
on the additions. Unicode and CSVs (Comma Separated Values) are now
|
|
|
|
supported.
|
|
|
|
|
2024-02-29 12:06:08 +00:00
|
|
|
fe86d923f83f:
|
|
|
|
usbconfig(8) now reads the descriptions of the usb vendor and products
|
2024-02-29 17:35:07 +00:00
|
|
|
from usb.ids when available, similarly to what pciconf(8) does.
|
2024-02-29 12:06:08 +00:00
|
|
|
|
2024-01-30 20:16:51 +00:00
|
|
|
4347ef60501f:
|
|
|
|
The powerd(8) utility is now enabled in /etc/rc.conf by default on
|
|
|
|
images for the arm64 Raspberry Pi's (arm64-aarch64-RPI img files).
|
|
|
|
This prevents the CPU clock from running slow all the time.
|
|
|
|
|
2024-01-17 12:59:03 +00:00
|
|
|
0b49e504a32d:
|
|
|
|
rc.d/jail now supports the legacy variable jail_${jailname}_zfs_dataset
|
|
|
|
to allow unmaintained jail managers like ezjail to make use of this
|
|
|
|
feature (simply rename jail_${jailname}_zfs_datasets in the ezjail
|
|
|
|
config to jail_${jailname}_zfs_dataset.
|
|
|
|
|
|
|
|
e0dfe185cbca:
|
|
|
|
jail(8) now support zfs.dataset to add a list of ZFS datasets to a
|
|
|
|
jail.
|
|
|
|
|
2023-12-29 08:45:52 +00:00
|
|
|
61174ad88e33:
|
|
|
|
newsyslog(8) now supports specifying a global compression method directly
|
|
|
|
at the beginning of the newsyslog.conf file, which will make newsyslog(8)
|
|
|
|
to behave like the corresponding option was passed to the newly added
|
|
|
|
'-c' option. For example:
|
|
|
|
|
|
|
|
<compress> none
|
|
|
|
|
|
|
|
906748d208d3:
|
|
|
|
newsyslog(8) now accepts a new option, '-c' which overrides all historical
|
|
|
|
compression flags by treating their meaning as "treat the file as compressible"
|
|
|
|
rather than "compress the file with that specific method."
|
|
|
|
|
|
|
|
The following choices are available:
|
|
|
|
* none: Do not compress, regardless of flag.
|
|
|
|
* legacy: Historical behavior (J=bzip2, X=xz, Y=zstd, Z=gzip).
|
|
|
|
* bzip2, xz, zstd, gzip: apply the specified compression method.
|
|
|
|
|
|
|
|
We plan to change the default to 'none' in FreeBSD 15.0.
|
|
|
|
|
2023-12-26 23:01:42 +00:00
|
|
|
1a878807006c:
|
|
|
|
This commit added some statistics collection to the NFS-over-TLS
|
|
|
|
code in the NFS server so that sysadmins can moditor usage.
|
|
|
|
The statistics are available via the kern.rpc.tls.* sysctls.
|
|
|
|
|
2023-12-22 20:25:19 +00:00
|
|
|
7c5146da1286:
|
|
|
|
Mountd has been modified to use strunvis(3) to decode directory
|
|
|
|
names in exports(5) file(s). This allows special characters,
|
|
|
|
such as blanks, to be embedded in the directory name(s).
|
|
|
|
"vis -M" may be used to encode such directory name(s).
|
|
|
|
|
2023-11-22 19:14:53 +00:00
|
|
|
c5359e2af5ab:
|
|
|
|
bhyve(8) has a new network backend, "slirp", which makes use of the
|
|
|
|
libslirp package to provide a userspace network stack. This backend
|
|
|
|
makes it possible to access the guest network from the host without
|
|
|
|
requiring any extra network configuration on the host.
|
|
|
|
|
2023-11-06 15:36:39 +00:00
|
|
|
bb830e346bd5:
|
|
|
|
Set the IUTF8 flag by default in tty(4).
|
|
|
|
|
|
|
|
128f63cedc14 and 9e589b093857 added proper UTF-8 backspacing handling
|
|
|
|
in the tty(4) driver, which is enabled by setting the new IUTF8 flag
|
|
|
|
through stty(1). Since the default locale is UTF-8, enable IUTF8 by
|
|
|
|
default.
|
|
|
|
|
2023-10-10 07:24:25 +00:00
|
|
|
ff01d71e48d4:
|
2023-10-10 11:39:36 +00:00
|
|
|
dialog(1) has been replaced by bsddialog(1)
|
2023-10-10 07:24:25 +00:00
|
|
|
|
2023-08-16 16:49:17 +00:00
|
|
|
41582f28ddf7:
|
|
|
|
FreeBSD 15.0 will not include support for 32-bit platforms.
|
|
|
|
However, 64-bit systems will still be able to run older 32-bit
|
|
|
|
binaries.
|
|
|
|
|
|
|
|
Support for executing 32-bit binaries on 64-bit platforms via
|
|
|
|
COMPAT_FREEBSD32 will remain supported for at least the
|
|
|
|
stable/15 and stable/16 branches.
|
|
|
|
|
|
|
|
Support for compiling individual 32-bit applications via
|
|
|
|
`cc -m32` will also be supported for at least the stable/15
|
|
|
|
branch which includes suitable headers in /usr/include and
|
|
|
|
libraries in /usr/lib32.
|
|
|
|
|
|
|
|
Support for 32-bit platforms in ports for 15.0 and later
|
|
|
|
releases is also deprecated, and these future releases may not
|
|
|
|
include binary packages for 32-bit platforms or support for
|
|
|
|
building 32-bit applications from ports.
|
|
|
|
|
|
|
|
stable/14 and earlier branches will retain existing 32-bit
|
|
|
|
kernel and world support. Ports will retain existing support
|
2023-08-17 21:25:44 +00:00
|
|
|
for building ports and packages for 32-bit systems on stable/14
|
2023-08-16 16:49:17 +00:00
|
|
|
and earlier branches as long as those branches are supported
|
|
|
|
by the ports system. However, all 32-bit platforms are Tier-2
|
|
|
|
or Tier-3 and support for individual ports should be expected
|
|
|
|
to degrade as upstreams deprecate 32-bit platforms.
|
|
|
|
|
|
|
|
With the current support schedule, stable/14 will be EOLed 5
|
|
|
|
years after the release of 14.0. The EOL of stable/14 would
|
|
|
|
mark the end of support for 32-bit platforms including source
|
|
|
|
releases, pre-built packages, and support for building
|
|
|
|
applications from ports. Given an estimated release date of
|
|
|
|
October 2023 for 14.0, support for 32-bit platforms would end
|
|
|
|
in October 2028.
|
|
|
|
|
|
|
|
The project may choose to alter this approach when 15.0 is
|
|
|
|
released by extending some level of 32-bit support for one or
|
|
|
|
more platforms in 15.0 or later. Users should use the
|
|
|
|
stable/14 branch to migrate off of 32-bit platforms.
|