This change adds some sample test cases to share/examples/tests/
demonstrating the basic usage of the atf and plain interfaces.
These test programs are fully-functional and are installed as part
of the test suite, which guarantees that the sample code remains
correct. However, they currently mostly serve as a placeholder for
additional examples and may be incomplete (depending on how you
look at them). I will see what else can be useful while working on
documentation.
As a bonus, the addition of these tests exercise the *.test.mk files,
one of which (plain.test.mk) was not yet in use, and also demonstrates
that it's possible to mix different kinds of test programs into the
same test suite.
Approved by: rpaulo (mentor)
This is to ensure that test-related directories don't get needlessly
created (and later deleted) when MK_TESTS=no.
Problem found by jhb@.
Approved by: rpaulo (mentor)
in net, to avoid compatibility breakage for no sake.
The future plan is to split most of non-kernel parts of
pfvar.h into pf.h, and then make pfvar.h a kernel only
include breaking compatibility.
Discussed with: bz
Populate /usr/tests with the only test programs that currently live
in the tree (those in lib/libcrypt/tests/) and add all the build
machinery to accompany this change.
In particular:
- Add a WITHOUT_TESTS variable that users can define to request that
no tests be put in /usr/tests.
- Add a top-level Kyuafile for /usr/tests and a way to create similar
Kyuafiles in top-level subdirectories.
- Add a BSD.tests.dist file to define the directory layout of
/usr/tests.
Submitted by: Julio Merino jmmv google.com
Reviewed by: sjg
MFC after: 2 weeks
we don't want to expose but which can't or shouldn't be static.
To mark a library as private, define PRIVATELIB in its Makefile. It
will be installed in LIBPRIVATEDIR, which is normally /usr/lib/private
(or /usr/lib32/private for 32-bit libraries on 64-bit platforms).
To indicate that a program or library depends on a private library,
define USEPRIVATELIB in its Makefile. The correct version of
LIBPRIVATEDIR will be added to its run-time library search path.
Approved by: re (blanket)
headrs.
Lots of third-party code expects to find C++03 headers under tr1 because that's
where GNU decided to hide them. This should fix ports that expect them there.
MFC after: 1 week
These are included unconditionally for now because bsdconfig
is currently installed unconditionally.
This fixes 'make -j 17 installworld' caused by a race
condition.
MFC candidate.
- Reconnect with some minor modifications, in particular now selsocket()
internals are adapted to use sbintime units after recent'ish calloutng
switch.
debug files for userland programs and libraries. The "-g" debug flag
is automatically applied when WITH_DEBUG_FILES is set.
The debug files are now named ${prog}.debug and ${shlib}.debug for
consistency with other systems and documentation. In addition they are
installed under /usr/lib/debug, to simplify the process of installing
them if needed after a crash. Users of bsd.{prog,lib}.mk outside of the
base system place the standalone debug files in a .debug subdirectory.
GDB automatically searches both of these directories for standalone
debug files.
Thanks to everyone who contributed changes, review, and testing during
development.
upcoming 3.3 release (branching and freezing expected in a few weeks).
Preliminary release notes can be found at the usual location:
<http://llvm.org/docs/ReleaseNotes.html>
An MFC is planned once the actual 3.3 release is finished.
auditdistd (distributed audit daemon) to the build:
- Manual cross references
- Makefile for auditdistd
- rc.d script, rc.conf entrie
- New group and user for auditdistd; associated aliases, etc.
The audit trail distribution daemon provides reliable,
cryptographically protected (and sandboxed) delivery of audit tails
from live clients to audit server hosts in order to both allow
centralised analysis, and improve resilience in the event of client
compromises: clients are not permitted to change trail contents
after submission.
Submitted by: pjd
Sponsored by: The FreeBSD Foundation (auditdistd)
but committing it helps to get everyone on the same page and makes
sure we make progress.
Tinderbox breakages that are the result of this commit are entirely
the committer's fault -- in other words: buildworld testing on amd64
only.
Credits follow:
Submitted by: Garrett Cooper <yanegomi@gmail.com>
Sponsored by: Isilon Systems
Based on work by: keramida@
Thanks to: gnn@, mdf@, mlaier@, sjg@
Special thanks to: keramida@
GIANT from VFS. In addition, disconnect also netsmb, which is a base
requirement for SMBFS.
In the while SMBFS regular users can use FUSE interface and smbnetfs
port to work with their SMBFS partitions.
Also, there are ongoing efforts by vendor to support in-kernel smbfs,
so there are good chances that it will get relinked once properly locked.
This is not targeted for MFC.
GIANT from VFS. This code is particulary broken and fragile and other
in-kernel implementations around, found in other operating systems,
don't really seem clean and solid enough to be imported at all.
If someone wants to reconsider in-kernel NTFS implementation for
inclusion again, a fair effort for completely fixing and cleaning it
up is expected.
In the while NTFS regular users can use FUSE interface and ntfs-3g
port to work with their NTFS partitions.
This is not targeted for MFC.
GIANT from VFS. In addition, disconnect also netncp, which is a base
requirement for NWFS.
In the possibility of a future maintenance of the code and later
readd to the FreeBSD base, maybe we should think about a better location
for netncp. I'm not entirely sure the / top location is actually right,
however I will let network people to comment on that more specifically.
This is not targeted for MFC.
to the build system. FreeBSD written scripts are stored in
src/share and the toolkit scripts are brought from the cddl directory
into a working tree via install.
MFC after: 2 weeks
The NAND Flash environment consists of several distinct components:
- NAND framework (drivers harness for NAND controllers and NAND chips)
- NAND simulator (NANDsim)
- NAND file system (NAND FS)
- Companion tools and utilities
- Documentation (manual pages)
This work is still experimental. Please use with caution.
Obtained from: Semihalf
Supported by: FreeBSD Foundation, Juniper Networks