each of the existing kernel configs. This gives a place to put config
that applies to the entire arch.
Add the ARM_NEW_PMAP option to std.armv6. This is working well in early
testing and it's time for wide exposure, but it's still nice to be able
to fall back to the old implementation for testing when a problem comes
along. Eventually the option and the old implementation will go away.
The opportunity now exists to move a whole lot of boilerplate from all the
arm kernel config files into std.arm*, but that's a commit for another day.
This was an optimization used only by a few xscale platforms. Part of
the optimization was to create a direct map for all physical pages, and
that resulted in making multiple mappings of pages in a way that bypassed
the logic in pmap.c to handle VIVT cache aliasing. It also just generally
made the code more complex and hard to maintain for all SoCs.
Reviewed by: cognet
in effect due to r250753. That is sufficient for all SoCs with a 32 byte
cache line size. Systems with 64 byte cache lines will need the option;
that will be done in a separate commit.
Thanks to loos@ for pointing out r250753.
this to the cache line size is required to avoid data corruption on armv4
and armv5, and improves performance on armv6, in both cases by avoiding
partial cacheline flushes for USB IO.
All these configs already exist in 10-stable. A few that don't (and
thus can't be MFC'd yet) will be committed separately.
* Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" option.
The files sha2.c, hash.c, randomdev_soft.c and yarrow.c comprise yarrow.
* random(4) device doesn't really depend on rijndael-*. Yarrow, however, does.
* Add random_adaptors.[ch] which is basically a store of random_adaptor's.
random_adaptor is basically an adapter that plugs in to random(4).
random_adaptor can only be plugged in to random(4) very early in bootup.
Unplugging random_adaptor from random(4) is not supported, and is probably a
bad idea anyway, due to potential loss of entropy pools.
We currently have 3 random_adaptors:
+ yarrow
+ rdrand (ivy.c)
+ nehemeiah
* Remove platform dependent logic from probe.c, and move it into
corresponding registration routines of each random_adaptor provider.
probe.c doesn't do anything other than picking a specific random_adaptor
from a list of registered ones.
* If the kernel doesn't have any random_adaptor adapters present then the
creation of /dev/random is postponed until next random_adaptor is kldload'ed.
* Fix randomdev_soft.c to refer to its own random_adaptor, instead of a
system wide one.
Submitted by: arthurmesh@gmail.com, obrien
Obtained from: Juniper Networks
Reviewed by: obrien
such that when commenting/uncommentting lines, horizontal spacing is
maintained...
Also fix some minor comment formatting to line things up, etc...
Reviewed by: gnn, imp
MFC after: 1 week
As of FreeBSD 8, this driver should not be used. Applications that use
posix_openpt(2) and openpty(3) use the pts(4) that is built into the
kernel unconditionally. If it turns out high profile depend on the
pty(4) module anyway, I'd rather get those fixed. So please report any
issues to me.
The pty(4) module is still available as a kernel module of course, so a
simple `kldload pty' can be used to run old-style pseudo-terminals.
NFSCL, NFSD instead of NFSCLIENT, NFSSERVER since
NFSCL and NFSD are now the defaults. The client change is
needed for diskless configurations, so that the root
mount works for fstype nfs.
Reported by seanbru at yahoo-inc.com for i386/XEN.
Approved by: re (hrs)
the 'debugging' section of any HEAD kernel and enable for the mainstream
ones, excluding the embedded architectures.
It may, of course, enabled on a case-by-case basis.
Sponsored by: Sandvine Incorporated
Requested by: emaste
Discussed with: kib
previously know by StarSemi STR9104.
Tested by the submitter on an Emprex NSD-100 board.
Submitted by: Yohanes Nugroho <yohanes at gmail.com>
Reviewed by: freebsd-arm, stas
Obtained from: //depot/projects/str91xx/...
