Commit Graph

1156 Commits

Author SHA1 Message Date
Ed Maste
6f282e722e Clarify UPDATING entry about lld
The workaround described in the 20180530 entry is no longer required.
Amend that entry and add a new 20180530 entry noting lld is the
default amd64 linker.

Reviewed by:	imp
Approved by:	re (kib)
2018-09-26 14:32:36 +00:00
Ian Lepore
0d77d170af If a user skips the pre-world mergemaster, an installworld check
notices the missing ntpd user and refers to UPDATING. This change makes
it more clear which aspect of UPDATING is important for the ntpd change.

PR:		231334
Approved by:	re (gjb)
2018-09-13 15:16:05 +00:00
Warner Losh
0fb707ecc9 Tweak typos in UPDATING
Approved by: re@ (gjb)
2018-08-29 17:37:23 +00:00
Mark Murray
19fa89e938 Remove the Yarrow PRNG algorithm option in accordance with due notice
given in random(4).

This includes updating of the relevant man pages, and no-longer-used
harvesting parameters.

Ensure that the pseudo-unit-test still does something useful, now also
with the "other" algorithm instead of Yarrow.

PR:		230870
Reviewed by:	cem
Approved by:	so(delphij,gtetlow)
Approved by:	re(marius)
Differential Revision:	https://reviews.freebsd.org/D16898
2018-08-26 12:51:46 +00:00
Warner Losh
592ffb2175 Revert drm2 removal.
Revert r338177, r338176, r338175, r338174, r338172

After long consultations with re@, core members and mmacy, revert
these changes. Followup changes will be made to mark them as
deprecated and prent a message about where to find the up-to-date
driver.  Followup commits will be made to make this clear in the
installer. Followup commits to reduce POLA in ways we're still
exploring.

It's anticipated that after the freeze, this will be removed in
13-current (with the residual of the drm2 code copied to
sys/arm/dev/drm2 for the TEGRA port's use w/o the intel or
radeon drivers).

Due to the impending freeze, there was no formal core vote for
this. I've been talking to different core members all day, as well as
Matt Macey and Glen Barber. Nobody is completely happy, all are
grudgingly going along with this. Work is in progress to mitigate
the negative effects as much as possible.

Requested by: re@ (gjb, rgrimes)
2018-08-24 00:02:00 +00:00
Warner Losh
84b9dfe433 Add a special note to UPDATING for the devmatch stuff. While tested,
there's an elevated risk of trouble, and you must update kernel,
userland and rc scripts for the best experience.
2018-08-23 05:06:31 +00:00
Matt Macy
d157fbd5b4 Remove legacy drm and drm2 from tree
As discussed on the MLs drm2 conflicts with the ports' version and there
is no upstream for most if not all of drm. Both have been merged in to
a single port.

Users on powerpc, 32-bit hardware, or with GPUs predating Radeon
and i915 will need to install the graphics/drm-legacy-kmod. All
other users should be able to use one of the LinuxKPI-based ports:
graphics/drm-stable-kmod, graphics/drm-next-kmod, graphics/drm-devel-kmod.

MFC: never
Approved by: core@
2018-08-22 01:50:12 +00:00
Warner Losh
295506bf9c Turn back the clock just a little: make userboot.so always be 4th
Turns out there was a hidden dependency we hasn't counted upon.  The
host load /boot/userboot.so to boot the VMs it runs. This means that
the change to lua meant suddently that nobody could run their older
VMs because LUA wasn't in 10.0, last month's HardenedBSD, 11.2 or
whatever.  Even more than for the /boot/loader* binaries, we need a
good coexistance strategy for this. While that's being designed and
implemented, drop back to always 4th for userboot.so. This will fail
safe in all but the most extreme environments (but lua-only hacks
to .lua files won't be processes in VMs until we fix it).

Differential Review: https://reviews.freebsd.org/D16805
2018-08-19 18:18:19 +00:00
Kyle Evans
f9f8ac94cd stand: Flip the default interpreter to Lua
After years in the making, lualoader is ready to make its debut. Both
flavors of loader are still built by default, and may be installed as
/boot/loader or /boot/loader.efi as appropriate either by manually creating
hard links or using LOADER_DEFAULT_INTERP as documented in build(7).

Discussed with:	imp
Relnotes:	yes
Differential Revision:	https://reviews.freebsd.org/D16795
2018-08-19 14:26:33 +00:00
Kyle Evans
e10ba80063 ls(1): Add --color=when
--color may be set to one of: 'auto', 'always', and 'never'.

'auto' is the default behavior- output colors only if -G or COLORTERM are
set, and only if stdout is a tty.

'always' is a new behavior- output colors always. termcap(5) will be
consulted unless TERM is unset or not a recognized terminal, in which case
ls(1) will fall back to explicitly outputting ANSI escape sequences.

'never' to turn off any environment variable and -G usage.

Reviewed by:	cem, 0mp (both modulo last-minute manpage changes
Differential Revision:	https://reviews.freebsd.org/D16741
2018-08-17 04:15:51 +00:00
Kyle Evans
72ad696aa1 Add post-mortem note to UPDATING about r337506
MFC after:	3 days
2018-08-15 19:28:48 +00:00
Alan Somers
47cc9ee1b1 Switch the default pager for most commands to less
Finally, a pager for the nineties.

MFC after:	Never
Relnotes:	Yes
Differential Revision:	https://reviews.freebsd.org/D13465
Poll:		https://reviews.freebsd.org/V7
2018-08-08 19:24:20 +00:00
Ravi Pokala
b598845049 Remove jedec_ts(4)
The jedec_ts(4) driver has been marked as deprecated in stable/11, and is
now being removed from -HEAD. Add a notice in UPDATING, and update the few
remaining references (regarding jedec_dimm(4)'s compatibility and history)
to reflect the fact that jedec_ts(4) is now deleted.

Reviewed by:	avg
Relnotes:	yes
Differential Revision:	https://reviews.freebsd.org/D16537
2018-08-01 08:24:34 +00:00
Kyle Evans
1ddc8a8e68 Follow up to r336919 and r336921: s/efi.rt_disabled/efi.rt.disabled/
The latter matches the rest of the tree better [0]. The UPDATING entry has
been updated to reflect this, and the new tunable is now documented in
loader(8) [1].

Reported by:	imp [0], Shawn Webb [1]
2018-07-30 18:13:20 +00:00
Kyle Evans
dfa6eec2b1 Correct typo from r336921; BIOS/legacy boot... 2018-07-30 17:59:18 +00:00
Kyle Evans
164138e7d8 amd64/GENERIC: Enable EFIRT by default
As noted in UDPATING, the new loader tunable efi.rt_disabled may be used to
disable EFIRT at runtime. It should have no effect if you are not booted via
UEFI boot.

MFC after:	6 weeks
2018-07-30 17:54:18 +00:00
Ed Maste
5f9d7aafd8 Correct typo and whitespace in UPDATING
PR:		230124
Submitted by:	Samy Mahmoudi
2018-07-30 00:04:42 +00:00
Emmanuel Vadot
c59a544e09 UPDATING: Add note about efifb support and serial output 2018-07-28 20:33:08 +00:00
Warner Losh
411e421961 Note ARM Atmel, Cavlium and XScale removal. 2018-07-27 21:40:05 +00:00
Warner Losh
07a522da1c Re-remove these empty directories 2018-07-27 21:36:29 +00:00
Warner Losh
663472df5a Say a little more about the new protocol.
Requested by: emaste@
2018-07-23 22:15:36 +00:00
Warner Losh
b43c6042c3 Finalize the boot manager protocol support for next-stage boot
loading.

If we are booting in a conforming UEFI Boot Manager Environment, then
use the BootCurrent variable to find the BootXXXX we're using. Once we
find that, then if it contains more than one EFI_DEVICE_PATH in its
what to boot section, try to use the last one as the kernel to
load. This will also set the default root partition as well. If
there's only one path, or if there's an error along the way, assume
that nothing specific was specified and revert to the old
algorithm. If something was specified, but not found, then fail the
boot. Otherwise you that, specific thing. On FreeBSD, this can be set
using efibootmgr -l <loader> -k <kernel>. We try a few variations of
kernel to cope with the fact that UEFI comes from a DOS world where
paths might be upper case and/or contain back-slashes.

Note: In an ideal world, we'd work out where we are in chain loading
by looking at the passed-in image handle and doing name
matching. However, that's unreliable since at least boot1.efi booted
images don't have that, hence the assumption that loader.efi needs to
load the last thing on the list, if possible.

The reason we fail for something specific is so that we can fully
participate in the UEFI Boot Manager Protocol and fail over to the
next item in the list of BootOrder choices when something goes wrong
at this stage.

This implements was was talked about in freebsd-arch@ last year
https://docs.freebsd.org/cgi/getmsg.cgi?fetch=3576+0+archive/2017/freebsd-arch/20171022.freebsd-arch
and documented in full (after changed resulting from the discussion) in
https://docs.google.com/document/d/1aK9IqF-60JPEbUeSAUAkYjF2W_8EnmczFs6RqCT90Jg/edit#
although one or two minor details may have been modified in this
implementation to make it work, and the ZFS MEDIA PATH extension isn't
implemented. This does not yet move things to ESP:\efi\freebsd\loader.efi.

RelNotes: Yes
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D16403
2018-07-23 20:36:59 +00:00
Ulrich Spörlein
2dc17d149e Remove duplicated entry 2018-07-23 08:52:57 +00:00
Warner Losh
3b74102205 Older zfs boot blocks don't support symlinks. install the link to
zfsloader as a hard link. While newer ones do, the whole point of the
link was to transition to the new world order smoothly. A hard link is
less flexible, but it works and will result in fewer bumps. Adjust
UPDATING entry to match.
2018-07-23 06:04:05 +00:00
Ian Lepore
d0e46652c1 Add a note about the new 'ntpd' userid, and the fact that rc.d/ntpd now
automatically runs the daemon as that user if it can.
2018-07-20 18:02:52 +00:00
Warner Losh
d397afa37d Mention zfsloader being folded into loader in UPDATING. 2018-07-20 05:26:36 +00:00
Warner Losh
dbe8ed38bf Note big endian arm removal. 2018-07-19 23:54:18 +00:00
Peter Jeremy
7bca8056ad Retrospectively document SVN branch point for stable-11
Approved by:	jhb (mentor)
Differential Revision:	https://reviews.freebsd.org/D16262
2018-07-17 11:35:40 +00:00
Kyle Evans
44314c3509 kern_environment: Give the static environment a chance to disable MD env
This variable has been given the name "loader_env.disabled" as it's the
primary way most people will have an MD environment. This restores the
previously-default behavior of ignoring the loader(8) environment, which may
be useful for vendor distributions or other scenarios where inheriting the
loader environment may be considered a security issue or potentially
breaking of a more locked-down environment.

As the change to config(5) indicates, disabling the loader environment
should not be a choice made lightly since it may provide ACPI hints and
other useful things that the system can rely on to boot.

An UPDATING entry has been added to mention an upgrade path for those that
may have relied on the previous behavior.

Discussed with:	bde
Relnotes:	yes (maybe)
2018-07-12 02:51:50 +00:00
Warner Losh
f06b6fdcb1 Mention the need to update devmatch.conf 2018-07-07 15:25:06 +00:00
Brooks Davis
f38b68ae8a Make struct xinpcb and friends word-size independent.
Replace size_t members with ksize_t (uint64_t) and pointer members
(never used as pointers in userspace, but instead as unique
idenitifiers) with kvaddr_t (uint64_t). This makes the structs
identical between 32-bit and 64-bit ABIs.

On 64-bit bit systems, the ABI is maintained. On 32-bit systems,
this is an ABI breaking change. The ABI of most of these structs
was previously broken in r315662.  This also imposes a small API
change on userspace consumers who must handle kernel pointers
becoming virtual addresses.

PR:		228301 (exp-run by antoine)
Reviewed by:	jtl, kib, rwatson (various versions)
Sponsored by:	DARPA, AFRL
Differential Revision:	https://reviews.freebsd.org/D15386
2018-07-05 13:13:48 +00:00
Matt Macy
f4b3640475 inline atomics and allow tied modules to inline locks
- inline atomics in modules on i386 and amd64 (they were always
  inline on other arches)
- allow modules to opt in to inlining locks by specifying
  MODULE_TIED=1 in the makefile

Reviewed by: kib
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D16079
2018-07-02 19:48:38 +00:00
Mariusz Zaborski
0dea6e3c98 core(5): overwrite the oldest core dump
The '%I' format in the kern.corefile sysctl limits the number of
core files that a process can generate to the number stored in the
debug.ncores sysctl. The '%I' format is replaced by the single digit
index. Previously, if all indexes were taken the kernel would overwrite
only a core file with the highest index in a filename.
Currently the system will create a new core file if there is a free
index or if all slots are taken it will overwrite the oldest one.

Reviewed by:	kib(code), bcr (updating)
Differential Revision:	https://reviews.freebsd.org/D15991
Differential Revision:	https://reviews.freebsd.org/D16084
2018-07-01 17:28:46 +00:00
Warner Losh
2fd8cef47f Mention, belatedly, the need to run mergemaster. This somehow
wasn't committed with the other changes.
2018-07-01 01:45:41 +00:00
Dimitry Andric
55458465af More follow-up to r335799 (llvm/clang 6.0.1 update), where I forgot to
update mtree files, ObsoleteFiles and a number of other paths.  Sorry
about all the breakage.

Pointy hat to:	me
MFC after:	2 weeks
X-MFC-With:	r335799
2018-06-30 15:03:22 +00:00
Glen Barber
197b832fbc Use the 'Updating from Source' Handbook section in UPDATING.
PR:		229345 (related)
Sponsored by:	The FreeBSD Foundation
2018-06-26 14:30:33 +00:00
Rick Macklem
fa986e33be Explain why a __FreeBSD_version bump was done for r334930. 2018-06-12 22:52:27 +00:00
Warner Losh
37d6a8f458 Revert size limits.
The size limits came from a flawed understanding of dump records.
The real issue was that dump was bogusly interpreting c_count
sometimes. r334978 fixes that.
2018-06-11 20:38:30 +00:00
Warner Losh
3bb3aaf6c1 Document the dump issue in UPDATING so people understand when they
get a new diagnostic.
2018-06-11 19:32:40 +00:00
Warner Losh
0bf7cdd502 Note the need for a new kernel / userland for devinfo to work
Differential Revision: https://reviews.freebsd.org/D15628
2018-05-31 02:58:08 +00:00
Warner Losh
212967ff26 We've removed the special case code for upgrading from FreeBSD 9 so
remove the special warning. It's in svn if we need it.
2018-05-30 05:00:30 +00:00
Ed Maste
0b979e7e8e UPDATING: remove EOL whitespace in 20180523 entry 2018-05-24 17:08:55 +00:00
Matt Macy
7e1a13f4b4 UPDATING: note that the pmc callchain ABI has changed 2018-05-23 17:30:23 +00:00
Sean Bruno
6f78fad3b1 Retire vxge(4).
This driver was merged to HEAD one week prior to Exar publicly announcing they
had left the Ethernet market. It is not known to be used and has various code
quality issues spotted by Brooks and Hiren. Retire it in preparation for
FreeBSD 12.0.

Submitted by:	kbowling
Reviewed by:	brooks imp
Relnotes:	yes
Sponsored by:	Limelight Networks
Differential Revision:	https://reviews.freebsd.org/D15442
2018-05-17 14:55:41 +00:00
Warner Losh
6e258ed363 2018 this time. 2018-05-16 21:07:12 +00:00
Warner Losh
eb8831b95c Add note about LD=ld.lld being a temporary requirement when building
the kernel the traditional way.
2018-05-16 13:52:24 +00:00
Sean Bruno
57b4936514 nxge(4):
Remove nxge(4) and associated man page and tools in FreeBSD 12.0.

Submitted by:	kbowling
Reviewed by:	brooks
Relnotes:	yes
Sponsored by:	Limelight Networks
Differential Revision:	https://reviews.freebsd.org/D1529
2018-05-08 21:14:29 +00:00
Philip Paeps
ba3833a8c4 Point out that the tzdata 2018e update brings in negative DST for certain time
zones.  This does not affect the vast majority of users who do not care about
(or even know about) the tm_isdst flag but may be slightly surprising to those
with a more specialised interest in time zone arcana.

MFC after:	3 days
2018-05-04 10:52:17 +00:00
Sean Bruno
2695c9c109 Retire ixgb(4)
This driver was for an early and uncommon legacy PCI 10GbE for a single
ASIC, Intel 82597EX. Intel quickly shifted to the long lived ixgbe family.

Submitted by:	kbowling
Reviewed by:	brooks imp jeffrey.e.pieper@intel.com
Relnotes:	yes
Sponsored by:	Limelight Networks
Differential Revision:	https://reviews.freebsd.org/D15234
2018-05-02 15:59:15 +00:00
Ed Maste
e6a376d196 Retire lmc(4)
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
2018-05-01 16:30:48 +00:00