netbsd-tests.test.mk (r289151)
- Eliminate explicit OBJTOP/SRCTOP setting
- Convert all ad hoc NetBSD test integration over to netbsd-tests.test.mk
- Remove unnecessary TESTSDIR setting
- Use SRCTOP where possible for clarity
MFC after: 2 weeks
Sponsored by: EMC / Isilon Storage Divison
Simplifying maintainance and options (only one place to deal with MK_DMAGENT)
This also makes packaging base less intrusive by getting a single point where
to add tags.
Plain test programs are not preprocessed by the build system (as opposed to
ATF test cases, which automatically gain a shebang pointing at atf-sh), so
we must take care of providing the shebang ourselves.
I'm not sure why this was not causing problems with Kyua 0.11, but the
upcoming 0.12 release chokes on this particular issue.
MFC after: 1 week
devmem is used to represent MMIO devices like the boot ROM or a VESA framebuffer
where doing a trap-and-emulate for every access is impractical. devmem is a
hybrid of system memory (sysmem) and emulated device models.
devmem is mapped in the guest address space via nested page tables similar
to sysmem. However the address range where devmem is mapped may be changed
by the guest at runtime (e.g. by reprogramming a PCI BAR). Also devmem is
usually mapped RO or RW as compared to RWX mappings for sysmem.
Each devmem segment is named (e.g. "bootrom") and this name is used to
create a device node for the devmem segment (e.g. /dev/vmm/testvm.bootrom).
The device node supports mmap(2) and this decouples the host mapping of
devmem from its mapping in the guest address space (which can change).
Reviewed by: tychon
Discussed with: grehan
Differential Revision: https://reviews.freebsd.org/D2762
MFC after: 4 weeks
Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
This is done if the installation mode is not requested or auto-detected.
This is useful when a kernel has to be loaded from multiple disks.
For example from a RAID-Z pool or a ZFS pool with multiple top level
vdevs.
Differential Revision: https://reviews.freebsd.org/D2723
Reviewed by: neel
MFC after: 8 days
- bootparamd
- bootpd
- finger/fingerd
- ftp/ftpd
- hastctl/hastd
- iscsid, et al
- rbootd
- talk/talkd
- tcpd, et al
- tftp/tftpd
Add src.conf entries for the various components and do a best effort
at adding components to tools/build/mk/OptionalObsoleteFiles.inc
This code has had an extensive rewrite and a good series of reviews, both by the author and other parties. This means a lot of code has been simplified. Pluggable structures for high-rate entropy generators are available, and it is most definitely not the case that /dev/random can be driven by only a hardware souce any more. This has been designed out of the device. Hardware sources are stirred into the CSPRNG (Yarrow, Fortuna) like any other entropy source. Pluggable modules may be written by third parties for additional sources.
The harvesting structures and consequently the locking have been simplified. Entropy harvesting is done in a more general way (the documentation for this will follow). There is some GREAT entropy to be had in the UMA allocator, but it is disabled for now as messing with that is likely to annoy many people.
The venerable (but effective) Yarrow algorithm, which is no longer supported by its authors now has an alternative, Fortuna. For now, Yarrow is retained as the default algorithm, but this may be changed using a kernel option. It is intended to make Fortuna the default algorithm for 11.0. Interested parties are encouraged to read ISBN 978-0-470-47424-2 "Cryptography Engineering" By Ferguson, Schneier and Kohno for Fortuna's gory details. Heck, read it anyway.
Many thanks to Arthur Mesh who did early grunt work, and who got caught in the crossfire rather more than he deserved to.
My thanks also to folks who helped me thresh this out on whiteboards and in the odd "Hallway track", or otherwise.
My Nomex pants are on. Let the feedback commence!
Reviewed by: trasz,des(partial),imp(partial?),rwatson(partial?)
Approved by: so(des)
The '-f' check works fine on a regular file but not if the backing file is
a device (e.g., /dev/md0). In this case it would print a misleading but
otherwise benign message about the backing file not being present.
Submitted by: Marcus Reid (marcus@blazingdot.com)
Discussed with: grehan
ISO will appear to be mounted on a /dev/cd device
instead of /dev/vtbd. This is similar to how other
virtualization environments handle mounting ISO images.
Reviewed by: neel
then it is no longer necessary to "bhyvectl --destroy" the VM when it reboots.
Move the "bhyvectl --destroy" outside of the while loop.
Reviewed by: neel
Update the copyright to be more in line with the current version in
our tree.
Remove the ancient rcsid.
Add a proper return from the main function
Pointed out by: bz
This particular program attempts to use the TSC to measure how long
certainly libpmc operations take. Depending on the quality of
the rdtsc() macro on a particular architecture this may work
more or less well.
This includes:
o All directories named *ia64*
o All files named *ia64*
o All ia64-specific code guarded by __ia64__
o All ia64-specific makefile logic
o Mention of ia64 in comments and documentation
This excludes:
o Everything under contrib/
o Everything under crypto/
o sys/xen/interface
o sys/sys/elf_common.h
Discussed at: BSDcan
is identified as "DOS/MBR boot sector" as opposed to "x86 boot sector".
This trips up vmrun.sh when using the new file(1) and makes it want to boot
into the installer instead.
Fix this by just looking for "boot sector" instead.
This allows you to give a bhyve instance multiple network devices
and disk devices easily by specifying additional "-d " and "-t "
options.
Reviewed by: neel
Sponsored by: Norse
