Re: svn commit: r335668 - head/sys/x86/xen
This breaks the kernel boot in EC2 Xen-based instances; it now hangs
in the taskqgroup_adjust_if_io_tqg SYSINIT. I've attached a verbose
dmesg from r335666 in case that helps you figure out what's going on.
My guess is that EC2 is numbering virtual CPUs oddly -- but regardless
of the cause, this definitely needs to be fixed.
Colin Percival
On 6/26/18 8:00 AM, Roger Pau Monné wrote:
> Author: royger
> Date: Tue Jun 26 15:00:54 2018
> New Revision: 335668
> URL: https://svnweb.freebsd.org/changeset/base/335668
>
> Log:
> xen: obtain vCPU ID from CPUID
>
> The Xen vCPU ID can be fetched from the cpuid instead of inferring it
> from the ACPI ID.
>
> Sponsored by: Citrix Systems R
>
> Modified:
> head/sys/x86/xen/hvm.c
>
> Modified: head/sys/x86/xen/hvm.c
> ==
> --- head/sys/x86/xen/hvm.cTue Jun 26 14:48:23 2018(r335667)
> +++ head/sys/x86/xen/hvm.cTue Jun 26 15:00:54 2018(r335668)
> @@ -56,6 +56,7 @@ __FBSDID("$FreeBSD$");
> #include
> #include
>
> +#include
> #include
> #include
>
> @@ -103,6 +104,9 @@ TUNABLE_INT("hw.xen.disable_pv_disks", _disable_pv
> TUNABLE_INT("hw.xen.disable_pv_nics", _disable_pv_nics);
>
> /*-- XEN Hypervisor Probe and Setup
> --*/
> +
> +static uint32_t cpuid_base;
> +
> static uint32_t
> xen_hvm_cpuid_base(void)
> {
> @@ -123,21 +127,21 @@ xen_hvm_cpuid_base(void)
> static int
> xen_hvm_init_hypercall_stubs(enum xen_hvm_init_type init_type)
> {
> - uint32_t base, regs[4];
> + uint32_t regs[4];
>
> if (xen_pv_domain()) {
> /* hypercall page is already set in the PV case */
> return (0);
> }
>
> - base = xen_hvm_cpuid_base();
> - if (base == 0)
> + cpuid_base = xen_hvm_cpuid_base();
> + if (cpuid_base == 0)
> return (ENXIO);
>
> if (init_type == XEN_HVM_INIT_COLD) {
> int major, minor;
>
> - do_cpuid(base + 1, regs);
> + do_cpuid(cpuid_base + 1, regs);
>
> major = regs[0] >> 16;
> minor = regs[0] & 0x;
> @@ -165,7 +169,7 @@ xen_hvm_init_hypercall_stubs(enum xen_hvm_init_type in
> /*
>* Find the hypercall pages.
>*/
> - do_cpuid(base + 2, regs);
> + do_cpuid(cpuid_base + 2, regs);
> if (regs[0] != 1)
> return (EINVAL);
>
> @@ -371,31 +375,14 @@ xen_hvm_sysinit(void *arg __unused)
> {
> xen_hvm_init(XEN_HVM_INIT_COLD);
> }
> +SYSINIT(xen_hvm_init, SI_SUB_HYPERVISOR, SI_ORDER_FIRST, xen_hvm_sysinit,
> NULL);
>
> static void
> -xen_set_vcpu_id(void)
> -{
> - struct pcpu *pc;
> - int i;
> -
> - if (!xen_hvm_domain())
> - return;
> -
> - /* Set vcpu_id to acpi_id */
> - CPU_FOREACH(i) {
> - pc = pcpu_find(i);
> - pc->pc_vcpu_id = pc->pc_acpi_id;
> - if (bootverbose)
> - printf("XEN: CPU %u has VCPU ID %u\n",
> -i, pc->pc_vcpu_id);
> - }
> -}
> -
> -static void
> xen_hvm_cpu_init(void)
> {
> struct vcpu_register_vcpu_info info;
> struct vcpu_info *vcpu_info;
> + uint32_t regs[4];
> int cpu, rc;
>
> if (!xen_domain())
> @@ -410,6 +397,22 @@ xen_hvm_cpu_init(void)
> return;
> }
>
> + /*
> + * Set vCPU ID. If available fetch the ID from CPUID, if not just use
> + * the ACPI ID.
> + */
> + KASSERT(cpuid_base != 0, ("Invalid base Xen CPUID leaf"));
> + cpuid_count(cpuid_base + 4, 0, regs);
> + PCPU_SET(vcpu_id, (regs[0] & XEN_HVM_CPUID_VCPU_ID_PRESENT) ?
> + regs[1] : PCPU_GET(acpi_id));
> +
> + /*
> + * Set the vCPU info.
> + *
> + * NB: the vCPU info for vCPUs < 32 can be fetched from the shared info
> + * page, but in order to make sure the mapping code is correct always
> + * attempt to map the vCPU info at a custom place.
> + */
> vcpu_info = DPCPU_PTR(vcpu_local_info);
> cpu = PCPU_GET(vcpu_id);
> info.mfn = vtophys(vcpu_info) >> PAGE_SHIFT;
> @@ -421,7 +424,4 @@ xen_hvm_cpu_init(void)
> else
> DPCPU_SET(vcpu_info, vcpu_info);
> }
> -
> -SYSINIT(xen_hvm_init, SI_SUB_HYPERVISOR, SI_ORDER_FIRST, xen_hvm_sysinit,
> NULL);
> SYSINIT(xen_hvm_cpu_init, SI_SUB_INTR, SI_ORDER_FIRST, xen_hvm_cpu_init,
> NULL);
> -SYSINIT(xen_set_vcpu_id, SI_SUB_CPU, SI_ORDER_ANY, xen_set_vcpu_id, NULL);
>
>
>
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r338331 - in head: include sys/sys
Author: delphij Date: Sun Aug 26 18:04:54 2018 New Revision: 338331 URL: https://svnweb.freebsd.org/changeset/base/338331 Log: Remove arc4random_stir and arc4random_addrandom from stdlib.h. 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) Modified: head/include/stdlib.h head/sys/sys/param.h Modified: head/include/stdlib.h == --- head/include/stdlib.h Sun Aug 26 17:05:43 2018(r338330) +++ head/include/stdlib.h Sun Aug 26 18:04:54 2018(r338331) @@ -254,12 +254,6 @@ voidarc4random_buf(void *, size_t); __uint32_t arc4random_uniform(__uint32_t); -#if !defined(BURN_BRIDGES) -/* Deprecated arc4random() functions */ -#define arc4random_stir() -#define arc4random_addrandom(a,b) -#endif - #ifdef __BLOCKS__ int atexit_b(void (^ _Nonnull)(void)); void *bsearch_b(const void *, const void *, size_t, Modified: head/sys/sys/param.h == --- head/sys/sys/param.hSun Aug 26 17:05:43 2018(r338330) +++ head/sys/sys/param.hSun Aug 26 18:04:54 2018(r338331) @@ -60,7 +60,7 @@ * in the range 5 to 9. */ #undef __FreeBSD_version -#define __FreeBSD_version 1200082 /* Master, propagated to newvers */ +#define __FreeBSD_version 1200083 /* Master, propagated to newvers */ /* * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD, ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r338330 - head/lib/libmd
> On Sun, 2018-08-26 at 10:15 -0700, Rodney W. Grimes wrote:
> > >
> > > On Sun, 2018-08-26 at 17:05 +, Sean Bruno wrote:
> > > >
> > > > Author: sbruno
> > > > Date: Sun Aug 26 17:05:43 2018
> > > > New Revision: 338330
> > > > URL: https://svnweb.freebsd.org/changeset/base/338330
> > > >
> > > > Log:
> > > > ? r338270 had the side effect of no longer installing libmd.so
> > > > into /lib.
> > > > ? For users who have a seperate zfs mount of /usr or /usr/lib,
> > > > this will
> > > > ? cause dynamic loading failures when attempting to execute zfs
> > > > mount on
> > > > ? bootup. E.g. the system won't boot.
> > > > ??
> > > > ? Including??sets SHLIBDIR, so SHLIBDIR?= has no
> > > > ? effect.??The other lib/ Makefiles solve this problem by moving
> > > > the
> > > > ? SHLIBDIR??assignment to before .include .
> > > > ??
> > > > ? Submitted by: jilles
> > > > ? Reviewed by: allanjude
> > > > ? Approved by: re (rgrimes)
> > > > ? Differential Revision:https://reviews.freebsd.org/D1691
> > > > 0
> > > >
> > > > Modified:
> > > > ? head/lib/libmd/Makefile
> > > >
> > > > Modified: head/lib/libmd/Makefile
> > > > =
> > > > =
> > > > --- head/lib/libmd/Makefile Sun Aug 26 13:08:50 2018
> > > > (r338329)
> > > > +++ head/lib/libmd/Makefile Sun Aug 26 17:05:43 2018
> > > > (r338330)
> > > > @@ -1,11 +1,12 @@
> > > > ?# $FreeBSD$
> > > > ?
> > > > +SHLIBDIR?= /lib
> > > > +
> > > > ?.include?
> > > > ?
> > > > ?PACKAGE=lib${LIB}
> > > > ?LIB= md
> > > > ?SHLIB_MAJOR= 6
> > > > -SHLIBDIR?= /lib
> > > > ?SRCS= md4c.c md5c.c md4hl.c md5hl.c \
> > > > ? rmd160c.c rmd160hl.c \
> > > > ? sha0c.c sha0hl.c sha1c.c sha1hl.c \
> > > >
> > > I'm curious why this is the preferred solution, as opposed to just
> > > leaving the assignment where it is and changing ?= to just =.
> > I think that reason would be that one could override
> > SHLIBDIR from a higher level, if they happened to
> > need to do that.??Ie, I could build a FreeBSD release
> > that had SHLIBDIR=/usr/lib from the top level and
> > it would just work.??(This can be done if you know
> > that / and /usr/lib well be in the same file system
> > for instance.??I could also build SHLIBDIR=/lib and
> > forgo the need for /usr/lib.
> >
>
> Oh, hmm. I wasn't thinking of that as a knob that would be controllable
> from outside of the build system internals. IMO, that whole subject is
> a bit of a weakness of the freebsd build machinery... we don't define,
> either via documentation or (better, IMO) via consistant variable and
> target name prefixes, which things are intended to be user-settable
> controls and which are intended only for internal use.
Back in the day it most of it was defined fairly well,
but over time as the complexity grew things have become
rather muddy.
I also suspect that there is probably some breakage if you
try to do what I mention above, but those are bugs that should
be fixed.
--
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r338330 - head/lib/libmd
On Sun, 2018-08-26 at 10:15 -0700, Rodney W. Grimes wrote:
> >
> > On Sun, 2018-08-26 at 17:05 +, Sean Bruno wrote:
> > >
> > > Author: sbruno
> > > Date: Sun Aug 26 17:05:43 2018
> > > New Revision: 338330
> > > URL: https://svnweb.freebsd.org/changeset/base/338330
> > >
> > > Log:
> > > ? r338270 had the side effect of no longer installing libmd.so
> > > into /lib.
> > > ? For users who have a seperate zfs mount of /usr or /usr/lib,
> > > this will
> > > ? cause dynamic loading failures when attempting to execute zfs
> > > mount on
> > > ? bootup. E.g. the system won't boot.
> > > ??
> > > ? Including sets SHLIBDIR, so SHLIBDIR?= has no
> > > ? effect.??The other lib/ Makefiles solve this problem by moving
> > > the
> > > ? SHLIBDIR??assignment to before .include .
> > > ??
> > > ? Submitted by: jilles
> > > ? Reviewed by:allanjude
> > > ? Approved by:re (rgrimes)
> > > ? Differential Revision: https://reviews.freebsd.org/D1691
> > > 0
> > >
> > > Modified:
> > > ? head/lib/libmd/Makefile
> > >
> > > Modified: head/lib/libmd/Makefile
> > > =
> > > =
> > > --- head/lib/libmd/Makefile Sun Aug 26 13:08:50 2018
> > > (r338329)
> > > +++ head/lib/libmd/Makefile Sun Aug 26 17:05:43 2018
> > > (r338330)
> > > @@ -1,11 +1,12 @@
> > > ?# $FreeBSD$
> > > ?
> > > +SHLIBDIR?= /lib
> > > +
> > > ?.include
> > > ?
> > > ?PACKAGE=lib${LIB}
> > > ?LIB= md
> > > ?SHLIB_MAJOR= 6
> > > -SHLIBDIR?= /lib
> > > ?SRCS=md4c.c md5c.c md4hl.c md5hl.c \
> > > ? rmd160c.c rmd160hl.c \
> > > ? sha0c.c sha0hl.c sha1c.c sha1hl.c \
> > >
> > I'm curious why this is the preferred solution, as opposed to just
> > leaving the assignment where it is and changing ?= to just =.
> I think that reason would be that one could override
> SHLIBDIR from a higher level, if they happened to
> need to do that. Ie, I could build a FreeBSD release
> that had SHLIBDIR=/usr/lib from the top level and
> it would just work. (This can be done if you know
> that / and /usr/lib well be in the same file system
> for instance. I could also build SHLIBDIR=/lib and
> forgo the need for /usr/lib.
>
Oh, hmm. I wasn't thinking of that as a knob that would be controllable
from outside of the build system internals. IMO, that whole subject is
a bit of a weakness of the freebsd build machinery... we don't define,
either via documentation or (better, IMO) via consistant variable and
target name prefixes, which things are intended to be user-settable
controls and which are intended only for internal use.
-- Ian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r338330 - head/lib/libmd
> On Sun, 2018-08-26 at 17:05 +, Sean Bruno wrote:
> > Author: sbruno
> > Date: Sun Aug 26 17:05:43 2018
> > New Revision: 338330
> > URL: https://svnweb.freebsd.org/changeset/base/338330
> >
> > Log:
> > ? r338270 had the side effect of no longer installing libmd.so into /lib.
> > ? For users who have a seperate zfs mount of /usr or /usr/lib, this will
> > ? cause dynamic loading failures when attempting to execute zfs mount on
> > ? bootup. E.g. the system won't boot.
> > ??
> > ? Including sets SHLIBDIR, so SHLIBDIR?= has no
> > ? effect.??The other lib/ Makefiles solve this problem by moving the
> > ? SHLIBDIR??assignment to before .include .
> > ??
> > ? Submitted by: jilles
> > ? Reviewed by: allanjude
> > ? Approved by: re (rgrimes)
> > ? Differential Revision:https://reviews.freebsd.org/D16910
> >
> > Modified:
> > ? head/lib/libmd/Makefile
> >
> > Modified: head/lib/libmd/Makefile
> > ==
> > --- head/lib/libmd/Makefile Sun Aug 26 13:08:50 2018(r338329)
> > +++ head/lib/libmd/Makefile Sun Aug 26 17:05:43 2018(r338330)
> > @@ -1,11 +1,12 @@
> > ?# $FreeBSD$
> > ?
> > +SHLIBDIR?= /lib
> > +
> > ?.include
> > ?
> > ?PACKAGE=lib${LIB}
> > ?LIB= md
> > ?SHLIB_MAJOR= 6
> > -SHLIBDIR?= /lib
> > ?SRCS= md4c.c md5c.c md4hl.c md5hl.c \
> > ? rmd160c.c rmd160hl.c \
> > ? sha0c.c sha0hl.c sha1c.c sha1hl.c \
> >
>
> I'm curious why this is the preferred solution, as opposed to just
> leaving the assignment where it is and changing ?= to just =.
I think that reason would be that one could override
SHLIBDIR from a higher level, if they happened to
need to do that. Ie, I could build a FreeBSD release
that had SHLIBDIR=/usr/lib from the top level and
it would just work. (This can be done if you know
that / and /usr/lib well be in the same file system
for instance. I could also build SHLIBDIR=/lib and
forgo the need for /usr/lib.
--
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r338330 - head/lib/libmd
On 08/26/18 11:11, Ian Lepore wrote:
>> Modified: head/lib/libmd/Makefile
>> ==
>> --- head/lib/libmd/Makefile Sun Aug 26 13:08:50 2018(r338329)
>> +++ head/lib/libmd/Makefile Sun Aug 26 17:05:43 2018(r338330)
>> @@ -1,11 +1,12 @@
>> # $FreeBSD$
>>
>> +SHLIBDIR?= /lib
>> +
>> .include
>>
>> PACKAGE=lib${LIB}
>> LIB=md
>> SHLIB_MAJOR= 6
>> -SHLIBDIR?= /lib
>> SRCS= md4c.c md5c.c md4hl.c md5hl.c \
>> rmd160c.c rmd160hl.c \
>> sha0c.c sha0hl.c sha1c.c sha1hl.c \
>>
> I'm curious why this is the preferred solution, as opposed to just
> leaving the assignment where it is and changing ?= to just =.
>
> -- Ian
>
>
I'm unsure if there is or isn't a preferred solution. There appear to
be multiple ways of doing this strewn about the tree.
This appears to be "a way" of fixing the state of -current at the
moment. I leave it to others more versed in the intricacies of Makefile
dark magic to scry a solution from the aether.
sean
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r338330 - head/lib/libmd
On Sun, 2018-08-26 at 17:05 +, Sean Bruno wrote:
> Author: sbruno
> Date: Sun Aug 26 17:05:43 2018
> New Revision: 338330
> URL: https://svnweb.freebsd.org/changeset/base/338330
>
> Log:
> r338270 had the side effect of no longer installing libmd.so into /lib.
> For users who have a seperate zfs mount of /usr or /usr/lib, this will
> cause dynamic loading failures when attempting to execute zfs mount on
> bootup. E.g. the system won't boot.
>
> Including sets SHLIBDIR, so SHLIBDIR?= has no
> effect. The other lib/ Makefiles solve this problem by moving the
> SHLIBDIR assignment to before .include .
>
> Submitted by: jilles
> Reviewed by:allanjude
> Approved by:re (rgrimes)
> Differential Revision: https://reviews.freebsd.org/D16910
>
> Modified:
> head/lib/libmd/Makefile
>
> Modified: head/lib/libmd/Makefile
> ==
> --- head/lib/libmd/Makefile Sun Aug 26 13:08:50 2018(r338329)
> +++ head/lib/libmd/Makefile Sun Aug 26 17:05:43 2018(r338330)
> @@ -1,11 +1,12 @@
> # $FreeBSD$
>
> +SHLIBDIR?= /lib
> +
> .include
>
> PACKAGE=lib${LIB}
> LIB= md
> SHLIB_MAJOR= 6
> -SHLIBDIR?= /lib
> SRCS=md4c.c md5c.c md4hl.c md5hl.c \
> rmd160c.c rmd160hl.c \
> sha0c.c sha0hl.c sha1c.c sha1hl.c \
>
I'm curious why this is the preferred solution, as opposed to just
leaving the assignment where it is and changing ?= to just =.
-- Ian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r338330 - head/lib/libmd
Author: sbruno
Date: Sun Aug 26 17:05:43 2018
New Revision: 338330
URL: https://svnweb.freebsd.org/changeset/base/338330
Log:
r338270 had the side effect of no longer installing libmd.so into /lib.
For users who have a seperate zfs mount of /usr or /usr/lib, this will
cause dynamic loading failures when attempting to execute zfs mount on
bootup. E.g. the system won't boot.
Including sets SHLIBDIR, so SHLIBDIR?= has no
effect. The other lib/ Makefiles solve this problem by moving the
SHLIBDIR assignment to before .include .
Submitted by: jilles
Reviewed by: allanjude
Approved by: re (rgrimes)
Differential Revision:https://reviews.freebsd.org/D16910
Modified:
head/lib/libmd/Makefile
Modified: head/lib/libmd/Makefile
==
--- head/lib/libmd/Makefile Sun Aug 26 13:08:50 2018(r338329)
+++ head/lib/libmd/Makefile Sun Aug 26 17:05:43 2018(r338330)
@@ -1,11 +1,12 @@
# $FreeBSD$
+SHLIBDIR?= /lib
+
.include
PACKAGE=lib${LIB}
LIB= md
SHLIB_MAJOR= 6
-SHLIBDIR?= /lib
SRCS= md4c.c md5c.c md4hl.c md5hl.c \
rmd160c.c rmd160hl.c \
sha0c.c sha0hl.c sha1c.c sha1hl.c \
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r338324 - in head: . share/man/man4 share/man/man9 sys/arm/amlogic/aml8726 sys/arm/broadcom/bcm2835 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/d...
Author: markm Date: Sun Aug 26 12:51:46 2018 New Revision: 338324 URL: https://svnweb.freebsd.org/changeset/base/338324 Log: 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 Deleted: head/sys/dev/random/yarrow.c head/sys/dev/random/yarrow.h head/sys/modules/random_yarrow/Makefile Modified: head/UPDATING head/share/man/man4/random.4 head/share/man/man9/random_harvest.9 head/sys/arm/amlogic/aml8726/aml8726_rng.c head/sys/arm/broadcom/bcm2835/bcm2835_rng.c head/sys/conf/NOTES head/sys/conf/files head/sys/conf/options head/sys/dev/glxsb/glxsb.c head/sys/dev/hifn/hifn7751.c head/sys/dev/random/build.sh head/sys/dev/random/fortuna.c head/sys/dev/random/other_algorithm.c head/sys/dev/random/other_algorithm.h head/sys/dev/random/random_harvestq.c head/sys/dev/random/random_harvestq.h head/sys/dev/random/randomdev.c head/sys/dev/random/unit_test.c head/sys/dev/random/unit_test.h head/sys/dev/rndtest/rndtest.c head/sys/dev/safe/safe.c head/sys/dev/syscons/scmouse.c head/sys/dev/syscons/syscons.c head/sys/dev/ubsec/ubsec.c head/sys/dev/virtio/random/virtio_random.c head/sys/dev/vt/vt_core.c head/sys/dev/vt/vt_sysmouse.c head/sys/fs/tmpfs/tmpfs_subr.c head/sys/kern/kern_intr.c head/sys/kern/subr_bus.c head/sys/mips/cavium/octeon_rnd.c head/sys/modules/Makefile head/sys/net/if_ethersubr.c head/sys/net/if_tun.c head/sys/netgraph/ng_iface.c head/sys/sys/random.h head/sys/ufs/ffs/ffs_inode.c head/sys/vm/uma_core.c head/tools/tools/sysdoc/tunables.mdoc Modified: head/UPDATING == --- head/UPDATING Sun Aug 26 05:28:17 2018(r338323) +++ head/UPDATING Sun Aug 26 12:51:46 2018(r338324) @@ -31,6 +31,11 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12.x IS SLOW: disable the most expensive debugging functionality run "ln -s 'abort:false,junk:false' /etc/malloc.conf".) +20180826: + The Yarrow CSPRNG has been removed from the kernel as it has not been + supported by its designers since at least 2003. Fortuna has been the + default since FreeBSD-11. + 20170822: devctl freeze/that have gone into the tree, the rc scripts have been updated to use them and devmatch has been changed. You should update Modified: head/share/man/man4/random.4 == --- head/share/man/man4/random.4Sun Aug 26 05:28:17 2018 (r338323) +++ head/share/man/man4/random.4Sun Aug 26 12:51:46 2018 (r338324) @@ -23,7 +23,7 @@ .\" .\" $FreeBSD$ .\" -.Dd August 17, 2015 +.Dd August 26, 2018 .Dt RANDOM 4 .Os .Sh NAME @@ -153,26 +153,15 @@ the device is not created until an "algorithm module" is loaded. -Two of these modules -are built by default, -.Em random_fortuna -and -.Em random_yarrow . +The only module built by default is +.Em random_fortuna . The .Em random_yarrow -module is deprecated, -and will be removed in -.Fx 12. -Use of the Yarrow algorithm -is not encouraged, -but while still present -in the kernel source, -it can be selected with the -.Cd "options RANDOM_YARROW" -kernel option. -Note that these loadable modules -are slightly less efficient -than their compiled-in equivalents. +module was removed in +.Fx 12 . +Note that this loadable module +is slightly less efficient +than its compiled-in equivalent. This is because some functions must be locked against load and unload events, @@ -351,4 +340,4 @@ introduced in The Yarrow algorithm is no longer supported by its authors, -and is therefore deprecated. +and is therefore no longer available. Modified: head/share/man/man9/random_harvest.9 == --- head/share/man/man9/random_harvest.9Sun Aug 26 05:28:17 2018 (r338323) +++ head/share/man/man9/random_harvest.9Sun Aug 26 12:51:46 2018 (r338324) @@ -25,7 +25,7 @@ .\" .\" $FreeBSD$ .\" -.Dd July 13, 2015 +.Dd August 26, 2018 .Dt RANDOM_HARVEST 9 .Os .Sh NAME @@ -38,21 +38,18 @@ .Fo random_harvest_direct .Fa "void *entropy" .Fa "u_int size" -.Fa "u_int bits" .Fa "enum esource source" .Fc .Ft void .Fo random_harvest_fast .Fa "void *entropy" .Fa "u_int size" -.Fa "u_int bits" .Fa "enum esource source" .Fc .
