#
256281 |
|
10-Oct-2013 |
gjb |
Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
253845 |
|
31-Jul-2013 |
obrien |
Back out r253779 & r253786.
|
#
253779 |
|
29-Jul-2013 |
obrien |
Decouple yarrow from random(4) device.
* 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
|
#
235118 |
|
07-May-2012 |
jmallett |
Add basic SMP support for GXemul. Ideally we would have some way to override some of the IPI mechanisms used by the common MIPS SMP code so we could use the multicast IPI facilities, on GXemul as well as on several real hardware platforms, and the ability to have multiple hard IPI types.
|
#
235117 |
|
07-May-2012 |
jmallett |
Add a trivial driver for the GXemul Ethernet device. Probably quite buggy and certainly non-optimal, but enough for basic networking use.
Requested by: rwatson
|
#
235073 |
|
06-May-2012 |
jmallett |
Add a driver for the GXemul test machine's disk controller and disk devices. Prefer it to using an md device in the GXEMUL kernel configuration.
Requested by: rwatson, theraven
|
#
234926 |
|
02-May-2012 |
rwatson |
mips/mips64eb became mips/mips64 while I wasn't looking (whoops), so update GXEMUL kernel config for the new world order.
Spotted by: bz MFC after: 3 weeks
|
#
234920 |
|
02-May-2012 |
rwatson |
Merge a rudimentary gxemul "oldtestmips" port. This consists almost entirely of one machdep file lifted from the MALTA port, as well as a low-level console and tty driver for the gxemul debugging console device (the emulators stdio). As with many low-level embedded and hypervisor console devices, it is polled only, so we drive TTY I/O from a callout; we are perhaps a bit too aware of the MIPS physical maps in order to attach the console before newbus comes to life.
The sample kernel configuration depends on an MD-based root file system, which is not provided. However, any 64-bit, big-endian userspace image (such as one generated for MALTA) should work.
This will hopefully be supplemented by additional device drivers for gxemul-specific hardware simulations from Juli Mallett. We have found oldtestmips quite useful for testing and improving aspects of the MIPS port, so it's worth supporting better in FreeBSD.
Requested by: theraven, jmallett Sponsored by: DARPA, AFRL MFC after: 3 weeks
|