tacit/minix
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Remove NetBSD references

Browse Source
This commit is contained in:
Eirikr Hinngart 2025-05-30 21:56:02 -07:00
parent 88b54bc197
commit 1bb6fd271a
41 changed files with 0 additions and 14641 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
bin/ed/README
View File

@ -1,24 +0,0 @@
$NetBSD: README,v 1.9 1995/03/21 09:04:33 cgd Exp $
ed is an 8-bit-clean, POSIX-compliant line editor. It should work with
any regular expression package that conforms to the POSIX interface
standard, such as GNU regex(3).
If reliable signals are supported (e.g., POSIX sigaction(2)), it should
compile with little trouble. Otherwise, the macros SPL1() and SPL0()
should be redefined to disable interrupts.
The following compiler directives are recognized:
DES - to add encryption support (requires crypt(3))
NO_REALLOC_NULL - if realloc(3) does not accept a NULL pointer
BACKWARDS - for backwards compatibility
NEED_INSQUE - if insque(3) is missing
The file `POSIX' describes extensions to and deviations from the POSIX
standard.
The ./test directory contains regression tests for ed. The README
file in that directory explains how to run these.
For a description of the ed algorithm, see Kernighan and Plauger's book
"Software Tools in Pascal," Addison-Wesley, 1981.

32
bin/ed/test/README
View File

@ -1,32 +0,0 @@
$NetBSD: README,v 1.8 1995/03/21 09:05:18 cgd Exp $
The files in this directory with suffixes `.t', `.d', `.r' and `.err' are
used for testing ed. To run the tests, set the ED variable in the Makefile
for the path name of the program to be tested (e.g., /bin/ed), and type
`make'. The tests do not exhaustively verify POSIX compliance nor do
they verify correct 8-bit or long line support.
The test file suffixes have the following meanings:
.t Template - a list of ed commands from which an ed script is
constructed
.d Data - read by an ed script
.r Result - the expected output after processing data via an ed
script.
.err Error - invalid ed commands that should generate an error
The output of the tests is written to the two files err.o and scripts.o.
At the end of the tests, these files are grep'ed for error messages,
which look like:
*** The script u.ed exited abnormally ***
or:
*** Output u.o of script u.ed is incorrect ***
The POSIX requirement that an address range not be used where at most
a single address is expected has been relaxed in this version of ed.
Therefore, the following scripts which test for compliance with this
POSIX rule exit abnormally:
=-err.ed
a1-err.ed
i1-err.ed
k1-err.ed
r1-err.ed

78
crypto/external/README vendored
View File

@ -1,78 +0,0 @@
$NetBSD: README,v 1.3 2012/01/28 01:30:42 christos Exp $
Organization of Sources:
This directory hierarchy is using an organization that separates
crypto source for programs that we have obtained from external third
parties (where NetBSD is not the primary maintainer) from the system
source.
This README file is derived from the README file in src/external.
The hierarchy is grouped by license, and then package per license,
and is organized as follows:
crypto/external/
Makefile
Descend into the license sub-directories.
<license>/
Per-license sub-directories.
Makefile
Descend into the package sub-directories.
<package>/
Per-package sub-directories.
Makefile
Build the package.
dist/
The third-party source for a given package.
bin/
lib/
sbin/
BSD makefiles "reach over" from these into
"../dist/".
This arrangement allows for packages to be easily disabled or
excised as necessary, either on a per-license or per-package basis.
The licenses currently used are:
bsd BSD (or equivalent) licensed software, possibly with
the "advertising clause".
cpl Common Public License
http://www.opensource.org/licenses/cpl1.0
If a package has components covered by different licenses
(for example, GPL2 and the LGPL), use the <license> subdirectory
for the more restrictive license.
If a package allows the choice of a license to use, we'll
generally use the less restrictive license.
If in doubt about where a package should be located, please
contact <core@NetBSD.org> for advice.
Migration Strategy:
Eventually src/dist (and associated framework in other base source
directories) and src/gnu will be migrated to this hierarchy.
Maintenance Strategy:
The sources under src/crypto/external/<license>/<package>/dist/ are
generally a combination of a published distribution plus changes
that we submit to the maintainers and that are not yet published
by them.
Make sure all changes made to the external sources are submitted
to the appropriate maintainer, but only after coordinating with
the NetBSD maintainers.

22
crypto/external/bsd/libsaslc/etc/README vendored
View File

@ -1,22 +0,0 @@
$NetBSD: README,v 1.1 2011/02/20 02:12:31 christos Exp $
These are example configuration files that are supposed to be installed
in /etc/saslc.d/ and are used to configure saslc globally as well as its
different authentication mechanisms.
The tree hierarchy looks like:
Default and global configuration files:
/etc/saslc.d/saslc/saslc.conf
/etc/saslc.d/saslc/mechs/{ANONYMOUS,CRAM-MD5,DIGEST-MD5}.conf
/etc/saslc.d/saslc/mechs/{EXTERNAL,GSSAPI,LOGIN,PLAIN}.conf
Custom configuration files for <program> (for example postfix):
/etc/saslc.d/<program>/saslc.conf
/etc/saslc.d/<program>/mechs/{ANONYMOUS,CRAM-MD5,DIGEST-MD5}.conf
/etc/saslc.d/<program>/mechs/{EXTERNAL,GSSAPI,LOGIN,PLAIN}.conf
Remember that some of the files contain sensitive information and should
be installed with the proper permissions (0600).

8478
crypto/external/bsd/netpgp/dist/src/netpgpverify/NetBSD-6.0_RC1_hashes.asc vendored
View File

File diff suppressed because it is too large Load Diff

BIN
crypto/external/bsd/netpgp/dist/src/netpgpverify/NetBSD-6.0_RC1_hashes.gpg vendored
View File

Binary file not shown.

72
distrib/sets/README
View File

@ -1,72 +0,0 @@
# $NetBSD: README,v 1.13 2013/08/06 22:33:59 soren Exp $
the scripts should be run from the directory where they reside.
makeflist: output the list of files that should be in a
distribution, according to the contents of the
'lists' directory.
checkflist: check the file list (as internally generated
by makeflist) against the tree living in $DESTDIR.
(that tree should be made with 'make distribution'.)
maketars: make tarballs of the various sets in the distribution,
based on the contents of the lists, the tree in
$DESTDIR, and put the tarballs in $RELEASEDIR.
Note that this script _doesn't_ create the 'secr'
distribution, because (for now) it requires
manual intervention to get the binaries right...
(i'll add another script to create that dist, later.)
what's in 'lists':
lists describing file sets. There are two sets of lists per file
set: machine dependent and machine-independent files. (there's
also another file in the 'man' dir, which is used by the 'man'
and 'misc' sets, but that's explained later.)
There is one machine-independent file, named "mi". There are
N machine-dependent files (one per architecture), named "md.${ARCH}".
the sets are as follows:
base: the base binary set. excludes everything described
below.
comp: compiler tools. All of the tools relating to C, C++,
and FORTRAN (yes, there are two!) that are in the
tree. This includes includes, the linker, tool chain,
and the .a versions of the libraries. (obviously,
base includes ldd, ld.so, and the shared versions.
base also includes 'cpp', because that's used by X11.)
includes the man pages for all the binaries contained
within. Also, includes all library and system call
manual pages.
debug: Debugging libraries (_g.a/MKDEBUGLIB) and (.debug/MKDEBUG)
binaries.
etc: /etc, and associated files (/var/cron/tabs, /root,
etc.). things that shouldn't be blindly reinstalled
on an upgrade.
games: the games and their man pages.
man: all of the man pages for the system, except those
listed elsewhere (e.g. in comp, games, misc, text).
Includes machine-dependent man pages for this CPU.
misc: share/dict, share/doc, and the machine-dependent
man pages for other CPUs which happen to always
be installed.
modules: stand/${MACHINE}/${OSRELEASE}/modules kernel modules
tests: unit, regression, integration and stress tests for the
whole system.
text: text processing tools. groff and all of its friends.
includes man pages for all bins contained within.
Each set must contain "./etc/mtree/set.<set name>" within the mi
list. Failure to add this will break unprivileged builds.

117
external/README vendored
View File

@ -1,117 +0,0 @@
$NetBSD: README,v 1.15 2012/06/14 04:14:36 riz Exp $
Organization of Sources:
This directory hierarchy is using an organization that separates
source for programs that we have obtained from external third
parties (where NetBSD is not the primary maintainer) from the
system source.
The hierarchy is grouped by license, and then package per license,
and is organized as follows:
external/
Makefile
Descend into the license sub-directories.
<license>/
Per-license sub-directories.
Makefile
Descend into the package sub-directories.
<package>/
Per-package sub-directories.
Makefile
Build the package.
dist/
The third-party source for a given package.
bin/
lib/
sbin/
BSD makefiles "reach over" from these into
"../dist/".
This arrangement allows for packages to be easily disabled or
excised as necessary, either on a per-license or per-package basis.
The licenses currently used are:
apache2 Apache 2.0 license.
http://www.opensource.org/licenses/apache2.0.php
atheros Atheros License.
bsd BSD (or equivalent) licensed software, possibly with
the "advertising clause".
http://www.opensource.org/licenses/bsd-license.php
cddl Common Development and Distribution License (the sun
license which is based on the Mozilla Public License
version 1.1).
http://www.opensource.org/licenses/cddl1.php
gpl2 GNU Public License, version 2 (or earlier).
http://www.opensource.org/licenses/gpl-2.0.php
gpl3 GNU Public License, version 3.
http://www.opensource.org/licenses/gpl-3.0.html
historical Lucent's old license:
http://www.opensource.org/licenses/historical.php
ibm-public IBM's public license:
http://www.opensource.org/licenses/ibmpl.php
intel-fw-eula Intel firmware license with redistribution
restricted to OEM.
intel-fw-public Intel firmware license permitting redistribution with
terms similar to BSD licensed software.
intel-public Intel license permitting redistribution with
terms similar to BSD licensed software.
mit MIT (X11) style license.
http://www.opensource.org/licenses/mit-license.php
public-domain Non-license for code that has been explicitly put
into the Public Domain.
realtek RealTek license.
zlib Zlib (BSD-like) license.
http://www.zlib.net/zlib_license.html
If a package has components covered by different licenses
(for example, GPL2 and the LGPL), use the <license> subdirectory
for the more restrictive license.
If a package allows the choice of a license to use, we'll
generally use the less restrictive license.
If in doubt about where a package should be located, please
contact <core@NetBSD.org> for advice.
Migration Strategy:
Eventually src/dist (and associated framework in other base source
directories) and src/gnu will be migrated to this hierarchy.
Maintenance Strategy:
The sources under src/external/<license>/<package>/dist/ are
generally a combination of a published distribution plus changes
that we submit to the maintainers and that are not yet published
by them.
Make sure all changes made to the external sources are submitted
to the appropriate maintainer, but only after coordinating with
the NetBSD maintainers.

11
external/bsd/atf/etc/atf/NetBSD.conf vendored
View File

@ -1,11 +0,0 @@
Content-Type: application/X-atf-config; version="1"
#
# Configuration file for the NetBSD test suite.
#
# See atf-formats(5) for details on the syntax of this file and tests(7) for
# details on the NetBSD test suite.
#
#variable1 = value1
#variable2 = value2

570
external/bsd/bind/dist/README vendored
View File

@ -1,570 +0,0 @@
BIND 9
BIND version 9 is a major rewrite of nearly all aspects of the
underlying BIND architecture. Some of the important features of
BIND 9 are:
- DNS Security
DNSSEC (signed zones)
TSIG (signed DNS requests)
- IP version 6
Answers DNS queries on IPv6 sockets
IPv6 resource records (AAAA)
Experimental IPv6 Resolver Library
- DNS Protocol Enhancements
IXFR, DDNS, Notify, EDNS0
Improved standards conformance
- Views
One server process can provide multiple "views" of
the DNS namespace, e.g. an "inside" view to certain
clients, and an "outside" view to others.
- Multiprocessor Support
- Improved Portability Architecture
BIND version 9 development has been underwritten by the following
organizations:
Sun Microsystems, Inc.
Hewlett Packard
Compaq Computer Corporation
IBM
Process Software Corporation
Silicon Graphics, Inc.
Network Associates, Inc.
U.S. Defense Information Systems Agency
USENIX Association
Stichting NLnet - NLnet Foundation
Nominum, Inc.
For a summary of functional enhancements in previous
releases, see the HISTORY file.
For a detailed list of user-visible changes from
previous releases, see the CHANGES file.
For up-to-date release notes and errata, see
http://www.isc.org/software/bind9/releasenotes
BIND 9.10.2-P4
BIND 9.10.2-P4 is a security release addressing the flaws
described in CVE-2015-5722 and CVE-2015-5986.
BIND 9.10.2-P3
BIND 9.10.2-P3 is a security release addressing the flaw
described in CVE-2015-5477.
BIND 9.10.2-P2
BIND 9.10.2-P2 is a security release addressing the flaw
described in CVE-2015-4620.
BIND 9.10.2-P1
BIND 9.10.2-P1 is a patch release addressing several
bugs recently found in the response-policy zones (RPZ)
implementation in BIND 9.10. These mostly affect servers
that have multiple frequently-updated response-policy
zones.
BIND 9.10.2
BIND 9.10.2 is a maintenance release and addresses bugs
found in BIND 9.10.1 and earlier, as well as the security
flaws described in CVE-2014-8500, CVE-2014-8680 and
CVE-2015-1349.
BIND 9.10.1
BIND 9.10.1 is a maintenance release and addresses bugs
found in BIND 9.10.0 and earlier.
This release addresses the security flaws described in
CVE-2014-3214 and CVE-2014-3859.
BIND 9.10.0
BIND 9.10.0 includes a number of changes from BIND 9.9 and earlier
releases. New features include:
- DNS Response-rate limiting (DNS RRL), which blunts the
impact of reflection and amplification attacks, is always
compiled in and no longer requires a compile-time option
to enable it.
- An experimental "Source Identity Token" (SIT) EDNS option
is now available. Similar to DNS Cookies as invented by
Donald Eastlake 3rd, these are designed to enable clients
to detect off-path spoofed responses, and to enable servers
to detect spoofed-source queries. Servers can be configured
to send smaller responses to clients that have not identified
themselves using a SIT option, reducing the effectiveness of
amplification attacks. RRL processing has also been updated;
clients proven to be legitimate via SIT are not subject to
rate limiting. Use "configure --enable-sit" to enable this
feature in BIND.
- A new zone file format, "map", stores zone data in a
format that can be mapped directly into memory, allowing
significantly faster zone loading.
- "delv" (domain entity lookup and validation) is a new tool
with dig-like semantics for looking up DNS data and performing
internal DNSSEC validation. This allows easy validation in
environments where the resolver may not be trustworthy, and
assists with troubleshooting of DNSSEC problems. (NOTE:
In previous development releases of BIND 9.10, this utility
was called "delve". The spelling has been changed to avoid
confusion with the "delve" utility included with the Xapian
search engine.)
- Improved EDNS(0) processing for better resolver performance
and reliability over slow or lossy connections.
- A new "configure --with-tuning=large" option tunes certain
compiled-in constants and default settings to values better
suited to large servers with abundant memory. This can
improve performance on such servers, but will consume more
memory and may degrade performance on smaller systems.
- Substantial improvement in response-policy zone (RPZ)
performance. Up to 32 response-policy zones can be
configured with minimal performance loss.
- To improve recursive resolver performance, cache records
which are still being requested by clients can now be
automatically refreshed from the authoritative server
before they expire, reducing or eliminating the time
window in which no answer is available in the cache.
- New "rpz-client-ip" triggers and drop policies allowing
response policies based on the IP address of the client.
- ACLs can now be specified based on geographic location
using the MaxMind GeoIP databases. Use "configure
--with-geoip" to enable.
- Zone data can now be shared between views, allowing
multiple views to serve the same zones authoritatively
without storing multiple copies in memory.
- New XML schema (version 3) for the statistics channel
includes many new statistics and uses a flattened XML tree
for faster parsing. The older schema is now deprecated.
- A new stylesheet, based on the Google Charts API, displays
XML statistics in charts and graphs on javascript-enabled
browsers.
- The statistics channel can now provide data in JSON
format as well as XML.
- New stats counters track TCP and UDP queries received
per zone, and EDNS options received in total.
- The internal and export versions of the BIND libraries
(libisc, libdns, etc) have been unified so that external
library clients can use the same libraries as BIND itself.
- A new compile-time option, "configure --enable-native-pkcs11",
allows BIND 9 cryptography functions to use the PKCS#11 API
natively, so that BIND can drive a cryptographic hardware
service module (HSM) directly instead of using a modified
OpenSSL as an intermediary. (Note: This feature requires an
HSM to have a full implementation of the PKCS#11 API; many
current HSMs only have partial implementations. The new
"pkcs11-tokens" command can be used to check API completeness.
Native PKCS#11 is known to work with the Thales nShield HSM
and with SoftHSM version 2 from the Open DNSSEC project.)
- The new "max-zone-ttl" option enforces maximum TTLs for
zones. This can simplify the process of rolling DNSSEC keys
by guaranteeing that cached signatures will have expired
within the specified amount of time.
- "dig +subnet" sends an EDNS CLIENT-SUBNET option when
querying.
- "dig +expire" sends an EDNS EXPIRE option when querying.
When this option is sent with an SOA query to a server
that supports it, it will report the expiry time of
a slave zone.
- New "dnssec-coverage" tool to check DNSSEC key coverage
for a zone and report if a lapse in signing coverage has
been inadvertently scheduled.
- Signing algorithm flexibility and other improvements
for the "rndc" control channel.
- "named-checkzone" and "named-compilezone" can now read
journal files, allowing them to process dynamic zones.
- Multiple DLZ databases can now be configured. Individual
zones can be configured to be served from a specific DLZ
database. DLZ databases now serve zones of type "master"
and "redirect".
- "rndc zonestatus" reports information about a specified zone.
- "named" now listens on IPv6 as well as IPv4 interfaces
by default.
- "named" now preserves the capitalization of names
when responding to queries: for instance, a query for
"example.com" may be answered with "example.COM" if the
name was configured that way in the zone file. Some
clients have a bug causing them to depend on the older
behavior, in which the case of the answer always matched
the case of the query, rather than the case of the name
configured in the DNS. Such clients can now be specified
in the new "no-case-compress" ACL; this will restore the
older behavior of "named" for those clients only.
- new "dnssec-importkey" command allows the use of offline
DNSSEC keys with automatic DNSKEY management.
- New "named-rrchecker" tool to verify the syntactic
correctness of individual resource records.
- When re-signing a zone, the new "dnssec-signzone -Q" option
drops signatures from keys that are still published but are
no longer active.
- "named-checkconf -px" will print the contents of configuration
files with the shared secrets obscured, making it easier to
share configuration (e.g. when submitting a bug report)
without revealing private information.
- "rndc scan" causes named to re-scan network interfaces for
changes in local addresses.
- On operating systems with support for routing sockets,
network interfaces are re-scanned automatically whenever
they change.
- "tsig-keygen" is now available as an alternate command
name to use for "ddns-confgen".
BIND 9.9.0
BIND 9.9.0 includes a number of changes from BIND 9.8 and earlier
releases. New features include:
- Inline signing, allowing automatic DNSSEC signing of
master zones without modification of the zonefile, or
"bump in the wire" signing in slaves.
- NXDOMAIN redirection.
- New 'rndc flushtree' command clears all data under a given
name from the DNS cache.
- New 'rndc sync' command dumps pending changes in a dynamic
zone to disk without a freeze/thaw cycle.
- New 'rndc signing' command displays or clears signing status
records in 'auto-dnssec' zones.
- NSEC3 parameters for 'auto-dnssec' zones can now be set prior
to signing, eliminating the need to initially sign with NSEC.
- Startup time improvements on large authoritative servers.
- Slave zones are now saved in raw format by default.
- Several improvements to response policy zones (RPZ).
- Improved hardware scalability by using multiple threads
to listen for queries and using finer-grained client locking
- The 'also-notify' option now takes the same syntax as
'masters', so it can used named masterlists and TSIG keys.
- 'dnssec-signzone -D' writes an output file containing only DNSSEC
data, which can be included by the primary zone file.
- 'dnssec-signzone -R' forces removal of signatures that are
not expired but were created by a key which no longer exists.
- 'dnssec-signzone -X' allows a separate expiration date to
be specified for DNSKEY signatures from other signatures.
- New '-L' option to dnssec-keygen, dnssec-settime, and
dnssec-keyfromlabel sets the default TTL for the key.
- dnssec-dsfromkey now supports reading from standard input,
to make it easier to convert DNSKEY to DS.
- RFC 1918 reverse zones have been added to the empty-zones
table per RFC 6303.
- Dynamic updates can now optionally set the zone's SOA serial
number to the current UNIX time.
- DLZ modules can now retrieve the source IP address of
the querying client.
- 'request-ixfr' option can now be set at the per-zone level.
- 'dig +rrcomments' turns on comments about DNSKEY records,
indicating their key ID, algorithm and function
- Simplified nsupdate syntax and added readline support
Building
BIND 9 currently requires a UNIX system with an ANSI C compiler,
basic POSIX support, and a 64 bit integer type.
We've had successful builds and tests on the following systems:
COMPAQ Tru64 UNIX 5.1B
Fedora Core 6
FreeBSD 4.10, 5.2.1, 6.2
HP-UX 11.11
Mac OS X 10.5
NetBSD 3.x, 4.0-beta, 5.0-beta
OpenBSD 3.3 and up
Solaris 8, 9, 9 (x86), 10
Ubuntu 7.04, 7.10
Windows XP/2003/2008
NOTE: As of BIND 9.5.1, 9.4.3, and 9.3.6, older versions of
Windows, including Windows NT and Windows 2000, are no longer
supported.
We have recent reports from the user community that a supported
version of BIND will build and run on the following systems:
AIX 4.3, 5L
CentOS 4, 4.5, 5
Darwin 9.0.0d1/ARM
Debian 4, 5, 6
Fedora Core 5, 7, 8
FreeBSD 6, 7, 8
HP-UX 11.23 PA
MacOS X 10.5, 10.6, 10.7
Red Hat Enterprise Linux 4, 5, 6
SCO OpenServer 5.0.6
Slackware 9, 10
SuSE 9, 10
To build, just
./configure
make
Do not use a parallel "make".
Several environment variables that can be set before running
configure will affect compilation:
CC
The C compiler to use. configure tries to figure
out the right one for supported systems.
CFLAGS
C compiler flags. Defaults to include -g and/or -O2
as supported by the compiler. Please include '-g'
if you need to set CFLAGS.
STD_CINCLUDES
System header file directories. Can be used to specify
where add-on thread or IPv6 support is, for example.
Defaults to empty string.
STD_CDEFINES
Any additional preprocessor symbols you want defined.
Defaults to empty string.
Possible settings:
Change the default syslog facility of named/lwresd.
-DISC_FACILITY=LOG_LOCAL0
Enable DNSSEC signature chasing support in dig.
-DDIG_SIGCHASE=1 (sets -DDIG_SIGCHASE_TD=1 and
-DDIG_SIGCHASE_BU=1)
Disable dropping queries from particular well known ports.
-DNS_CLIENT_DROPPORT=0
Sibling glue checking in named-checkzone is enabled by default.
To disable the default check set. -DCHECK_SIBLING=0
named-checkzone checks out-of-zone addresses by default.
To disable this default set. -DCHECK_LOCAL=0
To create the default pid files in ${localstatedir}/run rather
than ${localstatedir}/run/{named,lwresd}/ set.
-DNS_RUN_PID_DIR=0
Enable workaround for Solaris kernel bug about /dev/poll
-DISC_SOCKET_USE_POLLWATCH=1
The watch timeout is also configurable, e.g.,
-DISC_SOCKET_POLLWATCH_TIMEOUT=20
LDFLAGS
Linker flags. Defaults to empty string.
The following need to be set when cross compiling.
BUILD_CC
The native C compiler.
BUILD_CFLAGS (optional)
BUILD_CPPFLAGS (optional)
Possible Settings:
-DNEED_OPTARG=1 (optarg is not declared in <unistd.h>)
BUILD_LDFLAGS (optional)
BUILD_LIBS (optional)
On most platforms, BIND 9 is built with multithreading
support, allowing it to take advantage of multiple CPUs.
You can configure this by specifying "--enable-threads" or
"--disable-threads" on the configure command line. The default
is to enable threads, except on some older operating systems
on which threads are known to have had problems in the past.
(Note: Prior to BIND 9.10, the default was to disable threads on
Linux systems; this has been reversed. On Linux systems, the
threaded build is known to change BIND's behavior with respect
to file permissions; it may be necessary to specify a user with
the -u option when running named.)
To build shared libraries, specify "--with-libtool" on the
configure command line.
Certain compiled-in constants and default settings can be
increased to values better suited to large servers with abundant
memory resources (e.g, 64-bit servers with 12G or more of memory)
by specifying "--with-tuning=large" on the configure command
line. This can improve performance on big servers, but will
consume more memory and may degrade performance on smaller
systems.
For the server to support DNSSEC, you need to build it
with crypto support. You must have OpenSSL 0.9.5a
or newer installed and specify "--with-openssl" on the
configure command line. If OpenSSL is installed under
a nonstandard prefix, you can tell configure where to
look for it using "--with-openssl=/prefix".
To support the HTTP statistics channel, the server must
be linked with at least one of the following: libxml2
(http://xmlsoft.org) or json-c (https://github.com/json-c).
If these are installed at a nonstandard prefix, use
"--with-libxml2=/prefix" or "--with-libjson=/prefix".
On some platforms it is necessary to explicitly request large
file support to handle files bigger than 2GB. This can be
done by "--enable-largefile" on the configure command line.
Support for the "fixed" rrset-order option can be enabled
or disabled by specifying "--enable-fixed-rrset" or
"--disable-fixed-rrset" on the configure command line.
The default is "disabled", to reduce memory footprint.
If your operating system has integrated support for IPv6, it
will be used automatically. If you have installed KAME IPv6
separately, use "--with-kame[=PATH]" to specify its location.
"make install" will install "named" and the various BIND 9 libraries.
By default, installation is into /usr/local, but this can be changed
with the "--prefix" option when running "configure".
You may specify the option "--sysconfdir" to set the directory
where configuration files like "named.conf" go by default,
and "--localstatedir" to set the default parent directory
of "run/named.pid". For backwards compatibility with BIND 8,
--sysconfdir defaults to "/etc" and --localstatedir defaults to
"/var" if no --prefix option is given. If there is a --prefix
option, sysconfdir defaults to "$prefix/etc" and localstatedir
defaults to "$prefix/var".
To see additional configure options, run "configure --help".
Note that the help message does not reflect the BIND 8
compatibility defaults for sysconfdir and localstatedir.
If you're planning on making changes to the BIND 9 source, you
should also "make depend". If you're using Emacs, you might find
"make tags" helpful.
If you need to re-run configure please run "make distclean" first.
This will ensure that all the option changes take.
Building with gcc is not supported, unless gcc is the vendor's usual
compiler (e.g. the various BSD systems, Linux).
Known compiler issues:
* gcc-3.2.1 and gcc-3.1.1 is known to cause problems with solaris-x86.
* gcc prior to gcc-3.2.3 ultrasparc generates incorrect code at -02.
* gcc-3.3.5 powerpc generates incorrect code at -02.
* Irix, MipsPRO 7.4.1m is known to cause problems.
A limited test suite can be run with "make test". Many of
the tests require you to configure a set of virtual IP addresses
on your system, and some require Perl; see bin/tests/system/README
for details.
SunOS 4 requires "printf" to be installed to make the shared
libraries. sh-utils-1.16 provides a "printf" which compiles
on SunOS 4.
Known limitations
Linux requires kernel build 2.6.39 or later to get the
performance benefits from using multiple sockets.
Documentation
The BIND 9 Administrator Reference Manual is included with the
source distribution in DocBook XML and HTML format, in the
doc/arm directory.
Some of the programs in the BIND 9 distribution have man pages
in their directories. In particular, the command line
options of "named" are documented in /bin/named/named.8.
There is now also a set of man pages for the lwres library.
If you are upgrading from BIND 8, please read the migration
notes in doc/misc/migration. If you are upgrading from
BIND 4, read doc/misc/migration-4to9.
Frequently asked questions and their answers can be found in
FAQ.
Additional information on various subjects can be found
in the other README files.
Change Log
A detailed list of all changes to BIND 9 is included in the
file CHANGES, with the most recent changes listed first.
Change notes include tags indicating the category of the
change that was made; these categories are:
[func] New feature
[bug] General bug fix
[security] Fix for a significant security flaw
[experimental] Used for new features when the syntax
or other aspects of the design are still
in flux and may change
[port] Portability enhancement
[maint] Updates to built-in data such as root
server addresses and keys
[tuning] Changes to built-in configuration defaults
and constants to improve performance
[protocol] Updates to the DNS protocol such as new
RR types
[test] Changes to the automatic tests, not
affecting server functionality
[cleanup] Minor corrections and refactoring
[doc] Documentation
[contrib] Changes to the contributed tools and
libraries in the 'contrib' subdirectory
[placeholder] Used in the master development branch to
reserve change numbers for use in other
branches, e.g. when fixing a bug that only
exists in older releases
In general, [func] and [experimental] tags will only appear
in new-feature releases (i.e., those with version numbers
ending in zero). Some new functionality may be backported to
older releases on a case-by-case basis. All other change
types may be applied to all currently-supported releases.
Bug Reports and Mailing Lists
Bug reports should be sent to:
bind9-bugs@isc.org
Feature requests can be sent to:
bind-suggest@isc.org
To join or view the archives of the BIND Users mailing list,
visit:
https://lists.isc.org/mailman/listinfo/bind-users
If you're planning on making changes to the BIND 9 source
code, you may also want to join the BIND Workers mailing
list:
https://lists.isc.org/mailman/listinfo/bind-workers
Information on read-only Git access, coding style and developer
guidelines can be found at:
http://www.isc.org/git/
Acknowledgments
- This product includes software developed by the OpenSSL Project
for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/).
- This product includes cryptographic software written by Eric
Young (eay@cryptsoft.com).
- This product includes software written by Tim Hudson
(tjh@cryptsoft.com).

329
external/bsd/bind/dist/doc/arm/README-SGML vendored
View File

@ -1,329 +0,0 @@
Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
Copyright (C) 2000, 2001 Internet Software Consortium.
See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
The BIND v9 ARM master document is now kept in DocBook XML format.
Version: Id: README-SGML,v 1.17 2004/03/05 05:04:43 marka Exp
The entire ARM is in the single file:
Bv9ARM-book.xml
All of the other documents - HTML, PDF, etc - are generated from this
master source.
This file attempts to describe what tools are necessary for the
maintenance of this document as well as the generation of the
alternate formats of this document.
This file will also spend a very little time describing the XML and
SGML headers so you can understand a bit what you may need to do to be
able to work with this document in any fashion other than simply
editing it.
We will spend almost no time on the actual tags and how to write an
XML DocBook compliant document. If you are at all familiar with SGML
or HTML it will be very evident. You only need to know what the tags
are and how to use them. You can find a good resource either for this
either online or in printed form:
DocBook: The Definitive Guide
By Norman Walsh and Leonard Muellner
ISBN: 156592-580-7
1st Edition, October 1999
Copyright (C) 1999 by O'Reilly & Associates, Inc. All rights reserved.
The book is available online in HTML format:
http://docbook.org/
and buried in:
http://www.nwalsh.com/docbook/defguide/index.html
A lot of useful stuff is at NWalsh's site in general. You may also
want to look at:
http://www.xml.com/
The BIND v9 ARM is based on the XML 4.0 DocBook DTD. Every XML and
SGML document begins with a prefix that tells where to find the file
that describes the meaning and structure of the tags used in the rest
of the document.
For our XML DocBook 4.0 based document this prefix looks like this:
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.0//EN"
"/usr/local/share/xml/dtd/docbook/docbookx.dtd">
This "DOCTYPE" statement has three parts, of which we are only using
two:
o The highest level term that represents this document (in this case
it is "book"
o The identifier that tells us which DTD to use. This identifier has
two parts, the "Formal Public Identifier" (or FPI) and the system
identifier. In SGML you can have either a FPI or a SYSTEM identifier
but you have to have at least one of them. In XML you have to have a
SYSTEM identifier.
FP & SYSTEM identifiers - These are names/lookups for the actual
DTD. The FPI is a globally unique name that should, on a properly
configured system, tell you exactly what DTD to use. The SYSTEM
identifier gives an absolute location for the DTD. In XML these are
supposed to be properly formatted URL's.
SGML has these things called "catalogs" that are files that map FPI's
in to actual files. A "catalog" can also be used to remap a SYSTEM
identifier so you can say something like: "http://www.oasis.org/foo"
is actually "/usr/local/share/xml/foo.dtd"
When you use various SGML/XML tools they need to be configured to look
at the same "catalog" files so that as you move from tool to tool they
all refer to the same DTD for the same document.
We will be spending most of our configuration time making sure our
tools use the same "catalog" files and that we have the same DTD's
installed on our machines. XML's requirement of the SYSTEM identifier
over the FPI will probably lead to more problems as it does not
guarantee that everyone is using the same DTD.
I did my initial work with the "sgmltools" the XML 4.0 DocBook DTD and
"jade" or "openjade."
You can get the 4.0 XML DocBook DTD from:
http://www.docbook.org/xml/4.0/
(download the .zip file.) NOTE: We will eventually be changing the
SYSTEM identifier to the recommended value of:
http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd
NOTE: Under FreeBSD this is the package:
/usr/ports/textproc/docbook-xml
NetBSD instructions are coming soon.
With packages listed below installed under FreeBSD the "catalog" file
that all the tools refer to at least one is in:
/usr/local/share/sgml/catalog
In order for our SYSTEM identifier for the XML DocBook dtd to be found
I create a new catalog file at the top of the XML directory created on
FreeBSD:
/usr/local/share/xml/catalog
This file has one line:
SYSTEM "http://www.oasis-open.org/docbook/xml/4.0/docbookx.dtd" "/usr/local/share/xml/dtd/docbook/docbookx.dtd"
Then in the main "catalog" I have it include this XML catalog:
CATALOG "/usr/local/share/xml/catalog"
On your systems you need to replace "/usr/local/share" with your
prefix root (probably /usr/pkg under NetBSD.)
NOTE: The URL used above is supposed to the be the proper one for this
XML DocBook DTD... but there is nothing at that URL so you really do
need the "SYSTEM" identifier mapping in your catalog (or make the
SYSTEM identifier in your document refer to the real location of the
file on your local system.)
HOW TO VALIDATE A DOCUMENT:
I use the sgmltools "nsgmls" document validator. Since we are using
XML we need to use the XML declarations, which are installed as part
of the modular DSSL style sheets:
nsgmls -sv /usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \
Bv9ARM-book.xml
A convenient shell script "validate.sh" is now generated by configure
to invoke the above command with the correct system-dependent paths.
The SGML tools can be found at:
ftp://ftp.us.sgmltools.org/pub/SGMLtools/v2.0/source/ \
ftp://ftp.nllgg.nl/pub/SGMLtools/v2.0/source/
FreeBSD package for these is:
/usr/ports/textproc/sgmltools
HOW TO RENDER A DOCUMENT AS HTML or TeX:
o Generate html doc with:
openjade -v -d ./nominum-docbook-html.dsl \
-t sgml \
/usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \
Bv9ARM-book.xml
A convenient shell script "genhtml.sh" is now generated by configure to
invoke the above command with the correct system-dependent paths.
On NetBSD there is no port for "openjade" however "jade" does still
work. However you need to specify the "catalog" file to use for style
sheets on the command line AND you need to have a default "catalog"
mapping where to find various DTDs. It seems that "jade" installed out
of the box on NetBSD does not use a globally defined "catalog" file
for mapping PUBLIC identifiers in to SYSTEM identifiers.
So you need to have a "catalog" file in your current working directory
that has in it this: (these are probably more entries than you need!)
CATALOG "/usr/pkg/share/sgml/iso8879/catalog"
CATALOG "/usr/pkg/share/sgml/docbook/2.4.1/catalog"
CATALOG "/usr/pkg/share/sgml/docbook/3.0/catalog"
CATALOG "/usr/pkg/share/sgml/docbook/3.1/catalog"
CATALOG "/usr/pkg/share/sgml/jade/catalog"
CATALOG "/usr/local/share/xml/catalog"
(These would all be "/usr/local" on FreeBSD)
So the command for jade on NetBSD will look like this:
jade -v -c /usr/pkg/share/sgml/catalog -t sgml \
-d ./nominum-docbook-html.dsl \
/usr/pkg/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \
./Bv9ARM-book.xml
Furthermore, since the style sheet subset we define has in it a hard
coded path to the style sheet is based, it is actually generated by
configure from a .in file so that it will contain the correct
system-dependent path: where on FreeBSD the second line reads:
<!ENTITY dbstyle SYSTEM "/usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl" CDATA DSSSL>
On NetBSD it needs to read:
<!ENTITY dbstyle SYSTEM "/usr/pkg/share/sgml/docbook/dsssl/modular/html/docbook.dsl" CDATA DSSSL>
NOTE: This is usually solved by having this style sheet modification
be installed in a system directory and have it reference the style
sheet it is based on via a relative path.
o Generate TeX documentation:
openjade -d ./nominum-docbook-print.dsl -t tex -v \
/usr/local/share/sgml/docbook/dsssl/modular/dtds/decls/xml.dcl \
Bv9ARM-book.xml
If you have "jade" installed instead of "openjade" then use that as
the command. There is little difference, openjade has some bug fixes
and is in more active development.
To convert the resulting TeX file in to a DVI file you need to do:
tex "&jadetex" Bv9ARM-book.tex
You can also directly generate the pdf file via:
pdftex "&pdfjadetex" Bv9ARM-book.tex
The scripts "genpdf.sh" and "gendvi." have been added to simply
generating the PDF and DVI output. These substitute the correct paths
of NetBSD & FreeBSD. You still need to have TeX, jadeTeX, and pdfTeX
installed and configured properly for these to work.
You will need to up both the "pool_size" and "hash_extra" variables in
your texmf.cnf file and regenerate them. See below.
You can see that I am using a DSSSL style sheet for DocBook. Actually
two different ones - one for rendering html, and one for 'print'
media.
NOTE: For HTML we are using a Nominum DSSSL style instead of the
default one (all it does is change the chunking to the chapter level
and makes the files end with ".html" instead of ".htm" so far.) If you
want to use the plain jane DSSSL style sheet replace the:
-d ./nominum-docbook-html.dsl
with
-d /usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl
This style sheet will attempt to reference the one above.
I am currently working on fixing these up so that it works the same on
our various systems. The main trick is knowing which DTD's and DSSSL
stylesheets you have installed, installing the right ones, and
configuring a CATALOG that refers to them in the same way. We will
probably end up putting our CATALOG's in the same place and then we
should be able to generate and validate our documents with a minimal
number of command line arguments.
When running these commands you will get a lot of messages about a
bunch of general entities not being defined and having no default
entity. You can ignore those for now.
Also with the style sheets we have and jade as it is you will get
messages about "xref to title" being unsupported. You can ignore these
for now as well.
=== Getting the various tools installed on FreeBSD
(NetBSD coming soon..)
o On freebsd you need to install the following packages:
o print/teTeX
o textproc/openjade
o textproc/docbook
o textproc/docbook-xml
o textproc/dsssl-docbook-modular
o textproc/dtd-catalogs
o on freebsd you need to make some entities visible to the docbook xml
dtd by making a symlink (can probably be done with a catalog too)
ln -s /usr/local/share/xml/entity /usr/local/share/xml/dtd/docbook/ent
o you may need to edit /usr/local/share/sgml/catalog and add the line:
CATALOG "/usr/local/share/sgml/openjade/catalog"
o add "hugelatex," Enlarge pool sizes, install the jadetex TeX driver
file.
cd /usr/local/share/texmf/web2c/
sudo cp texmf.cnf texmf.cnf.bak
o edit the lines in texmf.cnf with these keys to these values:
main_memory = 1100000
hash_extra = 15000
pool_size = 500000
string_vacancies = 45000
max_strings = 55000
pool_free = 47500
nest_size = 500
param_size = 1500
save_size = 5000
stack_size = 1500
sudo tex -ini -progname=hugelatex -fmt=hugelatex latex.ltx
sudo texconfig init
sudo texhash
o For the jadetex macros you will need I recommend you get a more
current version than what is packaged with openjade or jade.
Checkout http://www.tug.org/applications/jadetex/
Unzip the file you get from there (should be jadetex-2.20 or
newer.)
In the directory you unzip:
sudo make install
sudo texhash
NOTE: In the most uptodate "ports" for FreeBSD, jadetext is 2.20+
so on this platform you should be set as of 2001.01.08.

21
external/bsd/bind/dist/unit/README vendored
View File

@ -1,21 +0,0 @@
These unit tests for BIND 9 are based on the NetBSD Automated Test Framework
release 0.17.
To build an external copy of ATF for use by BIND 9:
$ cd atf-src
$ configure --prefix=<prefix> --enable-tools --disable-shared
$ make
$ make install
Subsequently, specify the ATF prefix when building BIND 9:
$ configure --with-atf=<prefix>
ATF can also be built automatically during the BIND 9 build,
by specifying --with-atf without an argument:
$ configure --with-atf
This causes BIND 9 to build ATF in the atf-src directory and
link to it directly.

103
external/bsd/blacklist/README vendored
View File

@ -1,103 +0,0 @@
# $NetBSD: README,v 1.7 2015/01/26 00:34:50 christos Exp $
This package contains library that can be used by network daemons to
communicate with a packet filter via a daemon to enforce opening and
closing ports dynamically based on policy.
The interface to the packet filter is in libexec/blacklistd-helper
(this is currently designed for npf) and the configuration file
(inspired from inetd.conf) is in etc/blacklistd.conf.
On NetBSD you can find an example npf.conf and blacklistd.conf in
/usr/share/examples/blacklistd; you need to adjust the interface
in npf.conf and copy both files to /etc; then you just enable
blacklistd=YES in /etc/rc.conf, start it up, and you are all set.
There is also a startup file in etc/rc.d/blacklistd
Patches to various daemons to add blacklisting capabilitiers are in the
"diff" directory:
- OpenSSH: diff/ssh.diff [tcp socket example]
- Bind: diff/named.diff [both tcp and udp]
- ftpd: diff/ftpd.diff [tcp]
These patches have been applied to NetBSD-current.
The network daemon (for example sshd) communicates to blacklistd, via
a unix socket like syslog. The library calls are simple and everything
is handled by the library. In the simplest form the only thing the
daemon needs to do is to call:
blacklist(action, acceptedfd, message);
Where:
action = 0 -> successful login clear blacklist state
1 -> failed login, add to the failed count
acceptedfd -> the file descriptor where the server is
connected to the remote client. It is used
to determine the listening socket, and the
remote address. This allows any program to
contact the blacklist daemon, since the verification
if the program has access to the listening
socket is done by virtue that the port
number is retrieved from the kernel.
message -> an optional string that is used in debugging logs.
Unfortunately there is no way to get information about the "peer"
from a udp socket, because there is no connection and that information
is kept with the server. In that case the daemon can provide the
peer information to blacklistd via:
blacklist_sa(action, acceptedfd, sockaddr, sockaddr_len, message);
The configuration file contains entries of the form:
# Blacklist rule
# host/Port type protocol owner name nfail disable
192.168.1.1:ssh stream tcp * -int 10 1m
8.8.8.8:ssh stream tcp * -ext 6 60m
ssh stream tcp6 * * 6 60m
http stream tcp * * 6 60m
Here note that owner is * because the connection is done from the
child ssh socket which runs with user privs. We treat ipv4 connections
differently by maintaining two different rules one for the external
interface and one from the internal We also register for both tcp
and tcp6 since those are different listening sockets and addresses;
we don't bother with ipv6 and separate rules. We use nfail = 6,
because ssh allows 3 password attempts per connection, and this
will let us have 2 connections before blocking. Finally we block
for an hour; we could block forever too by specifying * in the
duration column.
blacklistd and the library use syslog(3) to report errors. The
blacklist filter state is persisted automatically in /var/db/blacklistd.db
so that if the daemon is restarted, it remembers what connections
is currently handling. To start from a fresh state (if you restart
npf too for example), you can use -f. To watch the daemon at work,
you can use -d.
The current control file is designed for npf, and it uses the
dynamic rule feature. You need to create a dynamic rule in your
/etc/npf.conf on the group referring to the interface you want to block
called blacklistd as follows:
ext_if=bge0
int_if=sk0
group "external" on $ext_if {
...
ruleset "blacklistd-ext"
ruleset "blacklistd"
...
}
group "internal" on $int_if {
...
ruleset "blacklistd-int"
...
}
Enjoy,
christos

718
external/bsd/dhcp/dist/README vendored
View File

@ -1,718 +0,0 @@
Internet Systems Consortium DHCP Distribution
Version 4.3.0
3 February 2014
README FILE
You should read this file carefully before trying to install or use
the ISC DHCP Distribution.
TABLE OF CONTENTS
1 WHERE TO FIND DOCUMENTATION
2 RELEASE STATUS
3 BUILDING THE DHCP DISTRIBUTION
3.1 UNPACKING IT
3.2 CONFIGURING IT
3.2.1 DYNAMIC DNS UPDATES
3.2.2 LOCALLY DEFINED OPTIONS
3.3 BUILDING IT
4 INSTALLING THE DHCP DISTRIBUTION
5 USING THE DHCP DISTRIBUTION
5.1 FIREWALL RULES
5.2 LINUX
5.2.1 IF_TR.H NOT FOUND
5.2.2 SO_ATTACH_FILTER UNDECLARED
5.2.3 PROTOCOL NOT CONFIGURED
5.2.4 BROADCAST
5.2.6 IP BOOTP AGENT
5.2.7 MULTIPLE INTERFACES
5.3 SCO
5.4 HP-UX
5.5 ULTRIX
5.6 FreeBSD
5.7 NeXTSTEP
5.8 SOLARIS
5.8.1 Solaris 11
5.8.2 Solaris 11 and ATF
5.8.3 Other Solaris Items
5.9 AIX
5.10 MacOS X
6 SUPPORT
6.1 HOW TO REPORT BUGS
7 HISTORY
WHERE TO FIND DOCUMENTATION
Documentation for this software includes this README file, the
RELNOTES file, and the manual pages, which are in the server, common,
client and relay subdirectories. The README file (this file) includes
late-breaking operational and system-specific information that you
should read even if you don't want to read the manual pages, and that
you should *certainly* read if you run into trouble. Internet
standards relating to the DHCP protocol are listed in the References
document that is available in html, txt and xml formats in doc/
subdirectory. You will have the best luck reading the manual pages if
you build this software and then install it, although you can read
them directly out of the distribution if you need to.
DHCP server documentation is in the dhcpd man page. Information about
the DHCP server lease database is in the dhcpd.leases man page.
Server configuration documentation is in the dhcpd.conf man page as
well as the dhcp-options man page. A sample DHCP server
configuration is in the file server/dhcpd.conf.example. The source for
the dhcpd, dhcpd.leases and dhcpd.conf man pages is in the server/ sub-
directory in the distribution. The source for the dhcp-options.5
man page is in the common/ subdirectory.
DHCP Client documentation is in the dhclient man page. DHCP client
configuration documentation is in the dhclient.conf man page and the
dhcp-options man page. The DHCP client configuration script is
documented in the dhclient-script man page. The format of the DHCP
client lease database is documented in the dhclient.leases man page.
The source for all these man pages is in the client/ subdirectory in
the distribution. In addition, the dhcp-options man page should be
referred to for information about DHCP options.
DHCP relay agent documentation is in the dhcrelay man page, the source
for which is distributed in the relay/ subdirectory.
To read installed manual pages, use the man command. Type "man page"
where page is the name of the manual page. This will only work if
you have installed the ISC DHCP distribution using the ``make install''
command (described later).
If you want to read manual pages that aren't installed, you can type
``nroff -man page |more'' where page is the filename of the
unformatted manual page. The filename of an unformatted manual page
is the name of the manual page, followed by '.', followed by some
number - 5 for documentation about files, and 8 for documentation
about programs. For example, to read the dhcp-options man page,
you would type ``nroff -man common/dhcp-options.5 |more'', assuming
your current working directory is the top level directory of the ISC
DHCP Distribution.
Please note that the pathnames of files to which our manpages refer
will not be correct for your operating system until after you iterate
'make install' (so if you're reading a manpage out of the source
directory, it may not have up-to-date information).
RELEASE STATUS
This is ISC DHCP 4.3.0. The major theme for this release is "ipv6 uplift",
in which we enhance the v6 code to support many of the features found
in the v4 code. These include: support for v6, support for on_commit,
on_expiry and on_release in v6, support for accessing v6 relay options
and better log messages for v6 addresses. Non v6 features include:
support for the standard DDNS, better OMAPI class and sub-class support
allowing for dynamic addition and removal of sub-classes, and support for
DDNS without zone statements.
In this release, the DHCPv6 server should be fully functional on Linux,
Solaris, or any BSD. The DHCPv6 client should be similarly functional
except on Solaris.
The DHCPv4 server, relay, and client, should be fully functional
on Linux, Solaris, any BSD, HPUX, SCO, NextSTEP, and Irix.
If you are running the DHCP distribution on a machine which is a
firewall, or if there is a firewall between your DHCP server(s) and
DHCP clients, please read the section on firewalls which appears later
in this document.
If you wish to run the DHCP Distribution on Linux, please see the
Linux-specific notes later in this document. If you wish to run on an
SCO release, please see the SCO-specific notes later in this document.
You particularly need to read these notes if you intend to support
Windows 95 clients. If you are running HP-UX or Ultrix, please read the
notes for those operating systems below. If you are running NeXTSTEP,
please see the notes on NeXTSTEP below.
If you start dhcpd and get a message, "no free bpf", that means you
need to configure the Berkeley Packet Filter into your operating
system kernel. On NetBSD, FreeBSD and BSD/os, type ``man bpf'' for
information. On Digital Unix, type ``man pfilt''.
BUILDING THE DHCP DISTRIBUTION
UNPACKING IT
To build the DHCP Distribution, unpack the compressed tar file using
the tar utility and the gzip command - type something like:
gunzip dhcp-4.3.0.tar.gz
tar xvf dhcp-4.3.0.tar
CONFIGURING IT
Now, cd to the dhcp-4.3.0 subdirectory that you've just created and
configure the source tree by typing:
./configure
If the configure utility can figure out what sort of system you're
running on, it will create a custom Makefile for you for that
system; otherwise, it will complain. If it can't figure out what
system you are using, that system is not supported - you are on
your own.
Several options may be enabled or disabled via the configure command.
You can get a list of these by typing:
./configure --help
DYNAMIC DNS UPDATES
A fully-featured implementation of dynamic DNS updates is included in
this release. It uses libraries from BIND and, to avoid issues with
different versions, includes the necessary BIND version. The appropriate
BIND libraries will be compiled and installed in the bind subdirectory
as part of the make step. In order to build the necessary libraries you
will need to have "gmake" available on your build system.
There is documentation for the DDNS support in the dhcpd.conf manual
page - see the beginning of this document for information on finding
manual pages.
LOCALLY DEFINED OPTIONS
In previous versions of the DHCP server there was a mechanism whereby
options that were not known by the server could be configured using
a name made up of the option code number and an identifier:
"option-nnn" This is no longer supported, because it is not future-
proof. Instead, if you want to use an option that the server doesn't
know about, you must explicitly define it using the method described
in the dhcp-options man page under the DEFINING NEW OPTIONS heading.
BUILDING IT
Once you've run configure, just type ``make'', and after a while
you should have a dhcp server. If you get compile errors on one
of the supported systems mentioned earlier, please let us know.
If you get warnings, it's not likely to be a problem - the DHCP
server compiles completely warning-free on as many architectures
as we can manage, but there are a few for which this is difficult.
If you get errors on a system not mentioned above, you will need
to do some programming or debugging on your own to get the DHCP
Distribution working.
INSTALLING THE DHCP DISTRIBUTION
Once you have successfully gotten the DHCP Distribution to build, you
can install it by typing ``make install''. If you already have an old
version of the DHCP Distribution installed, you may want to save it
before typing ``make install''.
USING THE DHCP DISTRIBUTION
FIREWALL RULES
If you are running the DHCP server or client on a computer that's also
acting as a firewall, you must be sure to allow DHCP packets through
the firewall. In particular, your firewall rules _must_ allow packets
from IP address 0.0.0.0 to IP address 255.255.255.255 from UDP port 68
to UDP port 67 through. They must also allow packets from your local
firewall's IP address and UDP port 67 through to any address your DHCP
server might serve on UDP port 68. Finally, packets from relay agents
on port 67 to the DHCP server on port 67, and vice versa, must be
permitted.
We have noticed that on some systems where we are using a packet
filter, if you set up a firewall that blocks UDP port 67 and 68
entirely, packets sent through the packet filter will not be blocked.
However, unicast packets will be blocked. This can result in strange
behaviour, particularly on DHCP clients, where the initial packet
exchange is broadcast, but renewals are unicast - the client will
appear to be unable to renew until it starts broadcasting its
renewals, and then suddenly it'll work. The fix is to fix the
firewall rules as described above.
PARTIAL SERVERS
If you have a server that is connected to two networks, and you only
want to provide DHCP service on one of those networks (e.g., you are
using a cable modem and have set up a NAT router), if you don't write
any subnet declaration for the network you aren't supporting, the DHCP
server will ignore input on that network interface if it can. If it
can't, it will refuse to run - some operating systems do not have the
capability of supporting DHCP on machines with more than one
interface, and ironically this is the case even if you don't want to
provide DHCP service on one of those interfaces.
LINUX
There are three big LINUX issues: the all-ones broadcast address,
Linux 2.1 ip_bootp_agent enabling, and operations with more than one
network interface. There are also two potential compilation/runtime
problems for Linux 2.1/2.2: the "SO_ATTACH_FILTER undeclared" problem
and the "protocol not configured" problem.
LINUX: PROTOCOL NOT CONFIGURED
If you get the following message, it's because your kernel doesn't
have the linux packetfilter or raw packet socket configured:
Make sure CONFIG_PACKET (Packet socket) and CONFIG_FILTER (Socket
Filtering) are enabled in your kernel configuration
If this happens, you need to configure your Linux kernel to support
Socket Filtering and the Packet socket, or to select a kernel provided
by your Linux distribution that has these enabled (virtually all modern
ones do by default).
LINUX: BROADCAST
If you are running a recent version of Linux, this won't be a problem,
but on older versions of Linux (kernel versions prior to 2.2), there
is a potential problem with the broadcast address being sent
incorrectly.
In order for dhcpd to work correctly with picky DHCP clients (e.g.,
Windows 95), it must be able to send packets with an IP destination
address of 255.255.255.255. Unfortunately, Linux changes an IP
destination of 255.255.255.255 into the local subnet broadcast address
(here, that's 192.5.5.223).
This isn't generally a problem on Linux 2.2 and later kernels, since
we completely bypass the Linux IP stack, but on old versions of Linux
2.1 and all versions of Linux prior to 2.1, it is a problem - pickier
DHCP clients connected to the same network as the ISC DHCP server or
ISC relay agent will not see messages from the DHCP server. It *is*
possible to run into trouble with this on Linux 2.2 and later if you
are running a version of the DHCP server that was compiled on a Linux
2.0 system, though.
It is possible to work around this problem on some versions of Linux
by creating a host route from your network interface address to
255.255.255.255. The command you need to use to do this on Linux
varies from version to version. The easiest version is:
route add -host 255.255.255.255 dev eth0
On some older Linux systems, you will get an error if you try to do
this. On those systems, try adding the following entry to your
/etc/hosts file:
255.255.255.255 all-ones
Then, try:
route add -host all-ones dev eth0
Another route that has worked for some users is:
route add -net 255.255.255.0 dev eth0
If you are not using eth0 as your network interface, you should
specify the network interface you *are* using in your route command.
LINUX: IP BOOTP AGENT
Some versions of the Linux 2.1 kernel apparently prevent dhcpd from
working unless you enable it by doing the following:
echo 1 >/proc/sys/net/ipv4/ip_bootp_agent
LINUX: MULTIPLE INTERFACES
Very old versions of the Linux kernel do not provide a networking API
that allows dhcpd to operate correctly if the system has more than one
broadcast network interface. However, Linux 2.0 kernels with version
numbers greater than or equal to 2.0.31 add an API feature: the
SO_BINDTODEVICE socket option. If SO_BINDTODEVICE is present, it is
possible for dhcpd to operate on Linux with more than one network
interface. In order to take advantage of this, you must be running a
2.0.31 or greater kernel, and you must have 2.0.31 or later system
headers installed *before* you build the DHCP Distribution.
We have heard reports that you must still add routes to 255.255.255.255
in order for the all-ones broadcast to work, even on 2.0.31 kernels.
In fact, you now need to add a route for each interface. Hopefully
the Linux kernel gurus will get this straight eventually.
Linux 2.1 and later kernels do not use SO_BINDTODEVICE or require the
broadcast address hack, but do support multiple interfaces, using the
Linux Packet Filter.
LINUX: OpenWrt
DHCP 4.1 has been tested on OpenWrt 7.09 and 8.09. In keeping with
standard practice, client/scripts now includes a dhclient-script file
for OpenWrt. However, this is not sufficient by itself to run dhcp on
OpenWrt; a full OpenWrt package for DHCP is available at
ftp://ftp.isc.org/isc/dhcp/dhcp-4.1.0-openwrt.tar.gz
LINUX: 802.1q VLAN INTERFACES
If you're using 802.1q vlan interfaces on Linux, it is necessary to
vconfig the subinterface(s) to rewrite the 802.1q information out of
packets received by the dhcpd daemon via LPF:
vconfig set_flag eth1.523 1 1
Note that this may affect the performance of your system, since the
Linux kernel must rewrite packets received via this interface. For
more information, consult the vconfig man pages.
SCO
ISC DHCP will now work correctly on newer versions of SCO out of the
box (tested on OpenServer 5.05b, assumed to work on UnixWare 7).
Older versions of SCO have the same problem as Linux (described earlier).
The thing is, SCO *really* doesn't want to let you add a host route to
the all-ones broadcast address.
You can try the following:
ifconfig net0 xxx.xxx.xxx.xxx netmask 0xNNNNNNNN broadcast 255.255.255.255
If this doesn't work, you can also try the following strange hack:
ifconfig net0 alias 10.1.1.1 netmask 8.0.0.0
Apparently this works because of an interaction between SCO's support
for network classes and the weird netmask. The 10.* network is just a
dummy that can generally be assumed to be safe. Don't ask why this
works. Just try it. If it works for you, great.
HP-UX
HP-UX has the same problem with the all-ones broadcast address that
SCO and Linux have. One user reported that adding the following to
/etc/rc.config.d/netconf helped (you may have to modify this to suit
your local configuration):
INTERFACE_NAME[0]=lan0
IP_ADDRESS[0]=1.1.1.1
SUBNET_MASK[0]=255.255.255.0
BROADCAST_ADDRESS[0]="255.255.255.255"
LANCONFIG_ARGS[0]="ether"
DHCP_ENABLE[0]=0
ULTRIX
Now that we have Ultrix packet filter support, the DHCP Distribution
on Ultrix should be pretty trouble-free. However, one thing you do
need to be aware of is that it now requires that the pfilt device be
configured into your kernel and present in /dev. If you type ``man
packetfilter'', you will get some information on how to configure your
kernel for the packet filter (if it isn't already) and how to make an
entry for it in /dev.
FreeBSD
Versions of FreeBSD prior to 2.2 have a bug in BPF support in that the
ethernet driver swaps the ethertype field in the ethernet header
downstream from BPF, which corrupts the output packet. If you are
running a version of FreeBSD prior to 2.2, and you find that dhcpd
can't communicate with its clients, you should #define BROKEN_FREEBSD_BPF
in site.h and recompile.
Modern versions of FreeBSD include the ISC DHCP 3.0 client as part of
the base system, and the full distribution (for the DHCP server and
relay agent) is available from the Ports Collection in
/usr/ports/net/isc-dhcp3, or as a package on FreeBSD installation
CDROMs.
NeXTSTEP
The NeXTSTEP support uses the NeXTSTEP Berkeley Packet Filter
extension, which is not included in the base NextStep system. You
must install this extension in order to get dhcpd or dhclient to work.
SOLARIS
There are two known issues seen when compiling using the Sun compiler.
The first is that older Sun compilers generate an error on some of
our uses of the flexible array option. Newer versions only generate
a warning, which can be safely ignored. If you run into this error
("type of struct member "buf" can not be derived from structure with
flexible array member"), upgrade your tools to Oracle Solaris Studio
(previously Sun Studio) 12 or something newer.
The second is the interaction between the configure script and the
makefiles for the Bind libraries. Currently we don't pass all
environment variables between the DHCP configure and the Bind configure.
If you attempt to specify the compiler you wish to use like this:
CC=/opt/SUNWspro/bin/cc ./configure
"make" may not build the Bind libraries with that compiler.
In order to use the same compiler for Bind and DHCP we suggest the
following commands:
CC=/opt/SUNWspro/bin/cc ./configure
CC=/opt/SUNWspro/bin/cc make
Solaris 11
We have integrated a patch from Oracle to use sockets instead of
DLPI on Solaris 11. This functionality was written for use with
Solaris Studio 12.2 and requires the system/header package.
By default this code is disabled in order to minimize disruptions
for current users. In order to enable this code you will need to
enable both USE_SOCKETS and USE_V4_PKTINFO as part of the
configuration step. The command line would be something like:
./configure --enable-use-sockets --enable-ipv4-pktinfo
Solaris 11 and ATF
We have reports that ATF 0.15 and 0.16 do not build on Solaris 11. The
following changes to the ATF source code appear to fix this issue:
diff -ru atf-0.15/atf-c/tp_test.c atf-0.15-patched/atf-c/tp_test.c
--- atf-0.15/atf-c/tp_test.c 2011-12-06 06:31:11.000000000 +0100
+++ atf-0.15-patched/atf-c/tp_test.c 2012-06-19 15:54:57.000000000 +0200
@@ -28,6 +28,7 @@
*/
#include <string.h>
+#include <stdio.h>
#include <unistd.h>
#include <atf-c.h>
diff -ru atf-0.15/atf-run/requirements.cpp atf-0.15-patched/atf-run/requirements.cpp
--- atf-0.15/atf-run/requirements.cpp 2012-01-13 20:44:25.000000000 +0100
+++ atf-0.15-patched/atf-run/requirements.cpp 2012-06-19 15:41:51.000000000 +0200
@@ -29,7 +29,7 @@
extern "C" {
#include <sys/param.h>
-#include <sys/sysctl.h>
+//#include <sys/sysctl.h>
}
#include <cerrno>
Other Solaris Items
One problem which has been observed and is not fixed in this
patchlevel has to do with using DLPI on Solaris machines. The symptom
of this problem is that the DHCP server never receives any requests.
This has been observed with Solaris 2.6 and Solaris 7 on Intel x86
systems, although it may occur with other systems as well. If you
encounter this symptom, and you are running the DHCP server on a
machine with a single broadcast network interface, you may wish to
edit the includes/site.h file and uncomment the #define USE_SOCKETS
line. Then type ``make clean; make''. As an alternative workaround,
it has been reported that running 'snoop' will cause the dhcp server
to start receiving packets. So the practice reported to us is to run
snoop at dhcpd startup time, with arguments to cause it to receive one
packet and exit.
snoop -c 1 udp port 67 > /dev/null &
The DHCP client on Solaris will only work with DLPI. If you run it
and it just keeps saying it's sending DHCPREQUEST packets, but never
gets a response, you may be having DLPI trouble as described above.
If so, we have no solution to offer at this time, aside from the above
workaround which should also work here. Also, because Solaris requires
you to "plumb" an interface before it can be detected by the DHCP client,
you must either specify the name(s) of the interface(s) you want to
configure on the command line, or must plumb the interfaces prior to
invoking the DHCP client. This can be done with ``ifconfig iface plumb'',
where iface is the name of the interface (e.g., ``ifconfig hme0 plumb'').
It should be noted that Solaris versions from 2.6 onward include a
DHCP client that you can run with ``/sbin/ifconfig iface dhcp start''
rather than using the ISC DHCP client, including DHCPv6. Consequently,
we don't believe there is a need for the client to run on Solaris, and
have not engineered the needed DHCPv6 modifications for the dhclient-script.
If you feel this is in error, or have a need, please contact us.
AIX
The AIX support uses the BSD socket API, which cannot differentiate on
which network interface a broadcast packet was received; thus the DHCP
server and relay will work only on a single interface. (They do work
on multi-interface machines if configured to listen on only one of the
interfaces.)
We have reports of Windows XP clients having difficulty retrieving
addresses from a server running on an AIX machine. This issue
was traced to the client requiring messages be sent to the all ones
broadcast address (255.255.255.255) while the AIX server was sending
to 192.168.0.255.
You may be able to solve this by including a relay between the client
and server with the relay configured to use a broadcast of all-ones.
A second option that worked for AIX 5.1 but doesn't seem to work for
AIX 5.3 was to:
create a host file entry for all-ones (255.255.255.255)
and then add a route:
route add -host all-ones -interface <local-ip-address>
The ISC DHCP distribution does not include a dhclient-script for AIX--
AIX comes with a DHCP client. Contribution of a working dhclient-script
for AIX would be welcome.
MacOS X
The MacOS X system uses a TCP/IP stack derived from FreeBSD with a
user-friendly interface named the System Configuration Framework.
As it includes a builtin DHCPv4 client (you are better just using that),
this text is only about the DHCPv6 client (``dhclient -6 ...''). The DNS
configuration (domain search list and name servers' addresses) is managed
by a System Configuration agent, not by /etc/resolv.conf (which is a link
to /var/run/resolv.conf, which itself only reflects the internal state;
the System Configuration framework's Dynamic Store).
This means that modifying resolv.conf directly doesn't have the
intended effect, instead the macos script sample creates its own
resolv.conf.dhclient6 in /var/run, and inserts the contents of this
file into the Dynamic Store.
When updating the address configuration the System Configuration
framework expects the prefix and a default router along with the
configured address. As this extra information is not available via
the DHCPv6 protocol the System Configuration framework isn't usable
for address configuration, instead ifconfig is used directly.
Note the Dynamic Store (from which /var/run/resolv.conf is built) is
recomputed from scratch when the current location/set is changed.
Running the dhclient-script reinstalls the resolv.conf.dhclient6
configuration.
SUPPORT
The Internet Systems Consortium DHCP server is developed and distributed
by ISC in the public trust, thanks to the generous donations of its
sponsors. ISC now also offers commercial quality support contracts for
ISC DHCP, more information about ISC Support Contracts can be found at
the following URL:
https://www.isc.org/services/support/
Please understand that we may not respond to support inquiries unless
you have a support contract. ISC will continue its practice of always
responding to critical items that effect the entire community, and
responding to all other requests for support upon ISC's mailing lists
on a best-effort basis.
However, ISC DHCP has attracted a fairly sizable following on the
Internet, which means that there are a lot of knowledgeable users who
may be able to help you if you get stuck. These people generally
read the dhcp-users@isc.org mailing list. Be sure to provide as much
detail in your query as possible.
If you are going to use ISC DHCP, you should probably subscribe to
the dhcp-users or dhcp-announce mailing lists.
WHERE TO SEND FEATURE REQUESTS: We like to hear your feedback. We may
not respond to it all the time, but we do read it. If ISC DHCP doesn't
work well for you, or you have an idea that would improve it for your
use, please send your suggestion to dhcp-suggest@isc.org. This is also
an excellent place to send patches that add new features.
WHERE TO REPORT BUGS: If you want the act of sending in a bug report
to result in you getting help in the form of a fixed piece of
software, you are asking for help. Your bug report is helpful to us,
but fundamentally you are making a support request, so please use the
addresses described in the previous paragraphs. If you are _sure_ that
your problem is a bug, and not user error, or if your bug report
includes a patch, you can send it to our ticketing system at
dhcp-bugs@isc.org. If you have not received a notice that the ticket
has been resolved, then we're still working on it.
PLEASE DO NOT REPORT BUGS IN OLD SOFTWARE RELEASES! Fetch the latest
release and see if the bug is still in that version of the software,
and if it is still present, _then_ report it. ISC release versions
always have three numbers, for example: 1.2.3. The 'major release' is
1 here, the 'minor release' is 2, and the 'maintenance release' is 3.
ISC will accept bug reports against the most recent two major.minor
releases: for example, 1.0.0 and 0.9.0, but not 0.8.* or prior.
PLEASE take a moment to determine where the ISC DHCP distribution
that you're using came from. ISC DHCP is sometimes heavily modified
by integrators in various operating systems - it's not that we
feel that our software is perfect and incapable of having bugs, but
rather that it is very frustrating to find out after many days trying
to help someone that the sources you're looking at aren't what they're
running. When in doubt, please retrieve the source distribution from
ISC's web page and install it.
HOW TO REPORT BUGS OR REQUEST HELP
When you report bugs or ask for help, please provide us complete
information. A list of information we need follows. Please read it
carefully, and put all the information you can into your initial bug
report. This will save us a great deal of time and more informative
bug reports are more likely to get handled more quickly overall.
1. The specific operating system name and version of the
machine on which the DHCP server or client is running.
2. The specific operating system name and version of the
machine on which the client is running, if you are having
trouble getting a client working with the server.
3. If you're running Linux, the version number we care about is
the kernel version and maybe the library version, not the
distribution version - e.g., while we don't mind knowing
that you're running Redhat version mumble.foo, we must know
what kernel version you're running, and it helps if you can
tell us what version of the C library you're running,
although if you don't know that off the top of your head it
may be hard for you to figure it out, so don't go crazy
trying.
4. The specific version of the DHCP distribution you're
running, as reported by dhcpd -t.
5. Please explain the problem carefully, thinking through what
you're saying to ensure that you don't assume we know
something about your situation that we don't know.
6. Include your dhcpd.conf and dhcpd.leases file as MIME attachments
if they're not over 100 kilobytes in size each. If they are
this large, please make them available to us eg via a hidden
http:// URL or FTP site. If you're not comfortable releasing
this information due to sensitive contents, you may encrypt
the file to our release signing key, available on our website.
7. Include a log of your server or client running until it
encounters the problem - for example, if you are having
trouble getting some client to get an address, restart the
server with the -d flag and then restart the client, and
send us what the server prints. Likewise, with the client,
include the output of the client as it fails to get an
address or otherwise does the wrong thing. Do not leave
out parts of the output that you think aren't interesting.
8. If the client or server is dumping core, please run the
debugger and get a stack trace, and include that in your
bug report. For example, if your debugger is gdb, do the
following:
gdb dhcpd dhcpd.core
(gdb) where
[...]
(gdb) quit
This assumes that it's the dhcp server you're debugging, and
that the core file is in dhcpd.core.
Please see https://www.isc.org/software/dhcp/ for details on how to subscribe
to the ISC DHCP mailing lists.
HISTORY
ISC DHCP was originally written by Ted Lemon under a contract with
Vixie Labs with the goal of being a complete reference implementation
of the DHCP protocol. Funding for this project was provided by
Internet Systems Consortium. The first release of the ISC DHCP
distribution in December 1997 included just the DHCP server.
Release 2 in June 1999 added a DHCP client and a BOOTP/DHCP relay
agent. DHCP 3 was released in October 2001 and included DHCP failover
support, OMAPI, Dynamic DNS, conditional behaviour, client classing,
and more. Version 3 of the DHCP server was funded by Nominum, Inc.
The 4.0 release in December 2007 introduced DHCPv6 protocol support
for the server and client.
This product includes cryptographic software written
by Eric Young (eay@cryptsoft.com).

7
external/bsd/elftoolchain/dist/libelf/os.NetBSD.mk vendored
View File

@ -1,7 +0,0 @@
#
# Build recipes for NetBSD.
#
# Id: os.NetBSD.mk 710 2010-02-17 14:21:38Z jkoshy
#
MKLINT= no # lint dies with a sigbus

106
external/bsd/libpcap/dist/README vendored
View File

@ -1,106 +0,0 @@
LIBPCAP 1.x.y
www.tcpdump.org
Please send inquiries/comments/reports to:
tcpdump-workers@lists.tcpdump.org
Anonymous Git is available via:
git clone git://bpf.tcpdump.org/libpcap
Please submit patches by forking the branch on GitHub at
http://github.com/the-tcpdump-group/libpcap/tree/master
and issuing a pull request.
formerly from Lawrence Berkeley National Laboratory
Network Research Group <libpcap@ee.lbl.gov>
ftp://ftp.ee.lbl.gov/old/libpcap-0.4a7.tar.Z
This directory contains source code for libpcap, a system-independent
interface for user-level packet capture. libpcap provides a portable
framework for low-level network monitoring. Applications include
network statistics collection, security monitoring, network debugging,
etc. Since almost every system vendor provides a different interface
for packet capture, and since we've developed several tools that
require this functionality, we've created this system-independent API
to ease in porting and to alleviate the need for several
system-dependent packet capture modules in each application.
For some platforms there are README.{system} files that discuss issues
with the OS's interface for packet capture on those platforms, such as
how to enable support for that interface in the OS, if it's not built in
by default.
The libpcap interface supports a filtering mechanism based on the
architecture in the BSD packet filter. BPF is described in the 1993
Winter Usenix paper ``The BSD Packet Filter: A New Architecture for
User-level Packet Capture''. A compressed PostScript version can be
found at
ftp://ftp.ee.lbl.gov/papers/bpf-usenix93.ps.Z
or
http://www.tcpdump.org/papers/bpf-usenix93.ps.Z
and a gzipped version can be found at
http://www.tcpdump.org/papers/bpf-usenix93.ps.gz
A PDF version can be found at
http://www.tcpdump.org/papers/bpf-usenix93.pdf
Although most packet capture interfaces support in-kernel filtering,
libpcap utilizes in-kernel filtering only for the BPF interface.
On systems that don't have BPF, all packets are read into user-space
and the BPF filters are evaluated in the libpcap library, incurring
added overhead (especially, for selective filters). Ideally, libpcap
would translate BPF filters into a filter program that is compatible
with the underlying kernel subsystem, but this is not yet implemented.
BPF is standard in 4.4BSD, BSD/OS, NetBSD, FreeBSD, OpenBSD, DragonFly
BSD, and Mac OS X; an older, modified and undocumented version is
standard in AIX. {DEC OSF/1, Digital UNIX, Tru64 UNIX} uses the
packetfilter interface but has been extended to accept BPF filters
(which libpcap utilizes). Also, you can add BPF filter support to
Ultrix using the kernel source and/or object patches available in:
http://www.tcpdump.org/other/bpfext42.tar.Z
Linux, in the 2.2 kernel and later kernels, has a "Socket Filter"
mechanism that accepts BPF filters; see the README.linux file for
information on configuring that option.
Note to Linux distributions and *BSD systems that include libpcap:
There's now a rule to make a shared library, which should work on Linux
and *BSD, among other platforms.
It sets the soname of the library to "libpcap.so.1"; this is what it
should be, *NOT* libpcap.so.1.x or libpcap.so.1.x.y or something such as
that.
We've been maintaining binary compatibility between libpcap releases for
quite a while; there's no reason to tie a binary linked with libpcap to
a particular release of libpcap.
Problems, bugs, questions, desirable enhancements, etc. should be sent
to the address "tcpdump-workers@lists.tcpdump.org". Bugs, support
requests, and feature requests may also be submitted on the GitHub issue
tracker for libpcap at
https://github.com/the-tcpdump-group/libpcap/issues
Source code contributions, etc. should be sent to the email address
above or submitted by forking the branch on GitHub at
http://github.com/the-tcpdump-group/libpcap/tree/master
and issuing a pull request.
Current versions can be found at www.tcpdump.org.
- The TCPdump team

65
external/gpl3/README vendored
View File

@ -1,65 +0,0 @@
$NetBSD: README,v 1.1 2010/04/01 14:13:25 reed Exp $
The code within the src/external/gplv3 directories may have serious
legal impacts if you are a company and redistributing or changing
this code (as a company holding patents). We recommend you contact
your lawyer before using it.
Please do not import new GPLv3 projects without Board approval.
--------------------------------------------------------------------
Statement for The NetBSD Foundation's Position on the GPLv3
NetBSD provides source code with the goal for anyone to be able
to use it for whatever they want, as long as they follow the simple
licensing terms. Historically, most of the original code used
Berkeley-style licensing and NetBSD's own code uses a simple
two-clause Berkeley-style license. To summarize: modifications are
allowed, the source code may be redistributed and the binaries (or
executables) may be distributed as long as the copyright and
disclaimer is included. NetBSD's code may be extended and sold
without sharing back the source code changes.
NetBSD also uses and redistributes source code and binaries from
source code obtained from external third parties. This source code
is segregated by placing it in the src/external and sys/src/external
directories which are categorized per license. Examples of this
include: ISC BIND, Solaris ZFS, CVS, GNU Binutils, Postfix, X.org
X Windowing System, and other software that are primarily maintained
outside of NetBSD.
In some cases, the third-party software is licensed under terms
that conflict with NetBSD's own goals. For example, the GPLv2 is
a "copyleft" license -- it requires that anyone who distributes
executable or object code based on the source code, also make the
source code and modifications available to the public. (NetBSD's
own code doesn't require companies to share their changes.)
The GPLv3 (GNU General Public License Version 3) includes clauses
that may cause additional burdens to developers or companies who
may modify the source code or ship products based on the source
code. The following summarizes some of these issues:
- The license allows the user to circumvent measures preventing
software changes (#3). This is known as the Tivoization clause.
In addition, this same clause is an anti-DRM, anti-DMCA clause --
as the developer allows the end-user to attempt to circumvent or
break the technological protection measures. Also, any information
or authorization keys required to install or run modified versions
must also be provided (#6).
- The patent clause (#11) says the copyright holders grant a
non-exclusive, worldwide, royalty-free patent license. You may be
required to extend the royalty-free patent license(s) to all
recipients or future users and developers who use the code. In
addition, you may not initiate litigation for a patent infringement
(#10).
We recommend companies redistributing GPLv3 licensed code to
consult their lawyer before using it.
It is the intent of the NetBSD project to use as little GPL licensed
software as possible to provide maximum freedom for development
and distribution of NetBSD derived products.

61
external/lgpl3/gmp/README vendored
View File

@ -1,61 +0,0 @@
$NetBSD: README,v 1.6 2013/12/04 11:43:52 mrg Exp $
GMP in NetBSD. We need GMP for GCC >= 4.2.
Building GMP without configure - how to port GMP build to a new platform.
The GMP build doesn't map very well to normal make. The ./configure phase
creates a bunch of symlinks and weeds out the sources lists, and there are
files with the same name in different subdirectories linked into the same
final product. All of these issues need to be dealt with.
There are a few steps to this:
- run ./configure, save the output. you can use the makefile
"Makefile.netbsd-gmp" in this directory to run this with the
right options, etc. run it with nbmake-$MACHINE.
- create src/external/gpl3/gmp/lib/libgmp/arch/${MACHINE_ARCH} dir,
and copy these files into it:
config.h
config.m4
gmp-mparam.h
gmp.h
mp.h
some of these files might have src/obj references. in particular
fix GMP_MPARAM_H_SUGGEST to start from ./mpn/... and make sure
we #define __GMP_CC to "gcc -std=gnu99", and make sure that
CONFIG_TOP_SRCDIR is not defined in config.m4
XXX make this automatic
- parse the ./configure output and note all created symlinks
for mpn. these need to be converted into a new Makefile.inc.
there is a script in this subdir build-gmp-Makefile.inc.awk
that can be used to do this. it should just work to generate
the first section of Makefile.inc if fed the entire configure
output.
assembler files generally want -DOPERATION_${foo} defined for
each way they are compiled or pre-processed. the pre-processor
used is m4 to parse, and we and create .s files from the .asm
files that we then we feed into $CC.
The amd64 port is a good reference to compare. The trialdivtab.h
generation may need to be moved the into libgmp/Makefile itself.
This mips64* ports need some minor hacks to the generated gmp*.h
files to fix their library builds for compat issues. See these
files in:
http://mail-index.netbsd.org/source-changes/2011/07/10/msg024467.html
This is still a work in progress and methods used to build may be
changed at any time.
mrg@netbsd.org
- 2011/06/22

41
games/fortune/README
View File

@ -1,41 +0,0 @@
# $NetBSD: README,v 1.2 1995/03/23 08:28:29 cgd Exp $
# @(#)README 8.1 (Berkeley) 5/31/93
The potentially offensive fortunes are not installed by default on BSD
systems. If you're absolutely, *positively*, without-a-shadow-of-a-doubt
sure that your user community wants them installed, whack the Makefile
in the subdirectory datfiles, and do "make all install".
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Some years ago, my neighbor Avery said to me: "There has not been an
adequate jokebook published since "Joe_Miller", which came out in 1739 and
which, incidentally, was the most miserable no-good ... jokebook in the
history of the printed word."
In a subsequent conversation, Avery said: "A funny story is a funny
story, no matter who is in it - whether it's about Catholics or Protestants,
Jews or Gentiles, blacks or whites, browns or yellows. If a story is genuinely
funny it makes no difference how dirty it is. Shout it from the rooftops.
Let the chips fall all over the prairie and let the bonehead wowsers yelp.
... on them."
It is a nice thing to have a neighbor of Avery's grain. He has
believed in the aforestated principles all his life. A great many other
people nowadays are casting aside the pietistic attitude that has led them
to plug up their ears against the facts of life. We of The Brotherhood
believe as Avery believes; we have never been intimidated by the pharisaical
meddlers who have been smelling up the American landscape since the time of
the bundling board. Neither has any one of our members ever been called a
racist. Still, we have been in unremitting revolt against the ignorant
propensity which ordains, in effect, that "The Green Pastures" should never
have been written; the idiot attitude which compelled Arthur Kober to abandon
his delightful Bella Gross, and Octavius Roy Cohen to quit writing about the
splendiferous Florian Slappey; the moronic frame of mind which, if carried
to its logical end, would have forbidden Ring Lardner from writing in the
language of the masses.
-- H. Allen Smith, "Rude Jokes"
... let us keep in mind the basic governing philosophy of The
Brotherhood, as handsomely summarized in these words: we believe in
healthy, hearty laughter -- at the expense of the whole human race, if
needs be.
Needs be.
-- H. Allen Smith, "Rude Jokes"

34
gnu/README
View File

@ -1,34 +0,0 @@
$NetBSD: README,v 1.5 2003/12/04 23:32:37 keihan Exp $
Organization of Sources:
This directory hierarchy is using a new organization that
separates the GNU sources from the BSD-style infrastructure
used to build the GNU sources. The GNU sources are kept in
the standard GNU source tree layout under:
dist/*
The build infrastructure uses the normal BSD way under:
lib/*
usr.bin/*
The makefiles in the above hierarchy will "reach over" into
the GNU sources (src/gnu/dist) for everything they need.
Maintenance Strategy:
The sources under src/gnu/dist are generally a combination of
some published distribution plus changes that we submit to the
maintainers and that are not yet published by them. There are
a few files that are never expected to be submitted to the FSF,
(i.e. BSD-style makefiles and such) and those generally should
stay in src/gnu/lib or src/gnu/usr.bin (the BSD build areas).
Make sure all changes made to the GNU sources are submitted to
the appropriate maintainer, but only after coordinating with the
NetBSD maintainers by sending your proposed submission to the
<tech-toolchain@NetBSD.org> mailing list. Only send the changes
to the third-party maintainers after consensus has been reached.

91
lib/csu/README
View File

@ -1,91 +0,0 @@
Introduction
This document covers the native NetBSD compiler runtime.
Machine independent sources can be found in common. The crtbegin.c in
that directory is a useful template for deriving compact assembler
versions. That is preferable to decouple the result from changes in the
compiler logic.
A new platform should provide the following content in
arch/${MACHINE_ARCH} or arch/${MACHINE_CPU}:
- Makefile.inc: provides ELFSIZE corresponding to 32/64bit file format.
If using the common C code instead of crtbegin.S also provide a -I option
to find crtbegin.h in your arch subdir.
- crt0.S: provides setup code and the call to ___start.
- crtbegin.S or crtbegin.h: see below
- crtend.S: see below, most likely just a copy of an existing architecture
- crti.S: prefix part of .init/.fini sections, i.e. to ensure stack alignment
- crtn.S: suffix part of the .init/.fini sections, i.e. return to caller.
Overview of the common runtime support
The common runtime support contains two modules, crtbegin and crtend.
crtbegin is linked before all other object files of the program or
dynamic library, crtend after all other object files. They frame the
lists of constructors, destructors, Java types and exception handling frames.
If done correctly, crtend contains no code and is therefore position
independent. crtendS.o is therefore just a link to crtend.o.
crtbegin should be position-independent code. crtbeginT.o doesn't have
to be PIC as it is statically linked. The overhead is generally not
worth the trouble though.
Section types:
.ctor: writeable
.dtor: writeable
.eh_frame: read-only if platform allows mixing read-only and read-write
sections. This is supported by GNU ld.
.jcr: writeable
.init: executable
.fini: executable
Non-local symbols:
Weak references:
- _Jv_RegisterClasses,
- __cxa_finalize (crtbeginS.o)
- __deregister_frame_info
- __register_frame_info
Hidden:
- __dso_handle: pointer to self for crtbeginS.o, NULL otherwise.
- __CTOR_LIST_END__
Initialisation (called from .init):
1. Check that the init code hasn't started already, otherwise bail out.
2. If __register_frame_info is NULL, skip to 4
3. Call __register_frame_info with start of .eh_frame as first argument
and a data object of at least 8 pointers as second argument.
4: If _Jv_RegisterClasses is NULL, skip to 6
5: Call _Jv_RegisterClasses with the first pointer of the .jcr section
as argument.
6: Iterate from the end of the .ctor section to the start. Skip the
terminating NULL and stop when reaching the starting (void *)-1 element.
Call the pointers as void (*)(void) functions.
Deinitialisation (called from .fini):
1. Check if the init code has already started, otherwise bail out.
2. If this is not crtbeginS.o or __cxa_finalize is NULL, skip to 4.
3. Call __cxa_finalize with a pointer into this Dynamic Shared Object (DSO)
as first argument.
4. Iterate from the start of the .dtor section to the send. Skip the
initial (void *)-1 and stop when reaching the terminating NULL element.
Call the pointers as void (*)(void) functions.
5. If __deregister_frame_info is NULL, return.
6. Call __deregister_frame_info with the start of .eh_frame as the argument.
Since most of this can easily be done in C code, instead of providing a
crtbegin.S you can also chose to use the generic C implementation. Provide
a crtbegin.h file instead of crtbegin.S. In there put inline assembler
stubs (mostly copied from some other arch) and implement calls to the
helper functions __do_global_ctors_aux/__do_global_dtors_aux.

239
lib/libc/README
View File

@ -1,239 +0,0 @@
$NetBSD: README,v 1.5 2015/07/11 15:23:57 riastradh Exp $
libc: The C library.
* ELF symbols and source names
libc contains symbols for:
(a) standard library routines in C and POSIX,
(b) published NetBSD-specific nonstandard extensions,
(c) internal symbols, and
(d) old versions of any published library routines.
** Standard library routines
If a library routine is standard and its signature has never changed,
it is provided as an ELF global symbol. Its name is declared normally
in the appropriate header file.
=> Example: The names `malloc' and `free' are declared normally in
<stdlib.h> (src/include/stdlib.h):
void *malloc(size_t);
void free(void *);
libc provides the following ELF symbols:
malloc global
free global
In the implementation of libc, malloc and free are defined normally
in src/lib/libc/stdlib/jemalloc.c:
void *
malloc(size_t size)
{
...
void
free(void *ptr)
{
...
** NetBSD-specific nonstandard extensions
If a library routine is nonstandard but published and its signature has
never changed, it is provided as an ELF weak symbol aliasing an ELF
global symbol of the same name with an underscore prefix.
The name is declared normally in the appropriate header file, provided
that the relevant feature macro, such as _NETBSD_SOURCE, is defined.
Within libc, the name is defined in "namespace.h"
(src/lib/libc/include/namespace.h) as a macro expanding to the
underscored name, which is included before the relevant header file, so
that
(a) the definition in a .c file will define the underscored ELF global
symbol, and
(b) the declaration in the standard header file will match the
definition in the .c file.
Alongside the definition in the .c file is a __weak_alias directive to
create the ELF weak symbol alias.
=> Example: For the nonstandard extension consttime_memequal, the
header file <string.h> (src/include/string.h) declares
`consttime_memequal' normally, if the caller defines _NETBSD_SOURCE:
#if defined(_NETBSD_SOURCE)
...
int consttime_memequal(const void *, const void *, size_t);
...
#endif /* _NETBSD_SOURCE */
libc provides the following ELF symbols:
_consttime_memequal global
consttime_memequal weak alias for _consttime_memequal
In the implementation of libc, the header file "namespace.h"
(src/lib/libc/include/namespace.h) defines `consttime_memequal' as a
macro expanding to `_consttime_memequal':
#define consttime_memequal _consttime_memequal
The source file src/common/lib/libc/string/consttime_memequal.c
includes "namespace.h" and <string.h>, and defines
`consttime_memequal' normally:
int
consttime_memequal(const void *b1, const void *b2, size_t len)
{
...
Macro expansion replaces `consttime_memequal' by
`_consttime_memequal', which is the ELF global symbol this defines.
Alongside the definition is
__weak_alias(consttime_memequal,_consttime_memequal)
to provide `consttime_memequal' as an ELF weak symbol aliasing
`_consttime_memequal'.
** Internal symbols
If a library routine is internal to libc, it is defined as an ELF
global symbol with an underscore prefix. Its name is declared in the
appropriate internal header file.
=> Example: The implementations of opendir and rewinddir use a common
subroutine _initdir, which is not part of the libc API or ABI -- it
is just an internal subroutine.
libc provides the following ELF symbols:
_initdir global
The name `_initdir' is declared normally in
src/lib/libc/gen/dirent_private.h:
int _initdir(DIR *, int, const char *);
The name `_initdir' is defined normally in
src/lib/libc/gen/initdir.c:
int
_initdir(DIR *dirp, int fd, const char *name)
{
...
** Old versions of library routines
If the signature or semantics of a library routine foo changed in (for
example) NetBSD 6.0, then libc provides
(1) an ELF global symbol `_foo' implementing its old signature,
(2) an ELF weak symbol `foo' aliasing `_foo', and
(3) an ELF global symbol `__foo50' implementing its new signature (yes,
`__foo50', not `__foo60').
The name foo is declared in the appropriate header file, under any
relevant feature macros, with a __RENAME directive so that for calls to
foo, the compiler will generate relocations for __foo50. Old programs,
compiled with the old signature, will continue to use the old symbol.
=> Example: In NetBSD 5.0, time_t was int32_t on every machine. In
NetBSD 6.0 and onward, time_t is int64_t on every machine.
Consequently, the signature of time(3), written as
time_t time(time_t *);
was effectively
int32_t time(int32_t *);
before NetBSD 6.0. In NetBSD 6.0, it changed to be effectively
int64_t time(int64_t *);
Before NetBSD 6.0, libc provided the following libc symbols:
_time global (implementing the old signature)
time weak alias for _time
In NetBSD 6.0 and later, libc provides the following ELF symbols:
_time global (implementing the old signature)
time weak alias for _time
__time50 global (implementing the new signature)
(Note that the only change is to add __time50, so that existing
programs linked against old versions of libc will see the same
semantics for the symbols that were already there.)
The header file <time.h> (src/include/time.h) declares
time_t time(time_t *) __RENAME(__time50);
so that compiling C programs that call time will yield objects that
use the __time50 symbol from libc. However, old programs that were
compiled against the 32-bit declaration will continue to use the
32-bit symbol from libc.
The header file "namespace.h" (src/lib/libc/include/namespace.h)
defines `time' as a macro expanding to `_time':
#define time _time
The source file src/lib/libc/gen/time.c includes "namespace.h" and
<time.h> and defines `time' normally:
time_t
time(time_t *t)
{
...
Macro expansion replaces `time' by `_time', but the
`__RENAME(__time50)' directive on the declaration <time.h> (to which
the "namespace.h" macro expansion also applies) means the ELF global
symbol defined here is actually `__time50'.
The header file <compat/include/time.h>
(src/lib/libc/compat/include/time.h) declares
int32_t time(int32_t *);
The source file src/lib/libc/compat/gen/compat_time.c includes
"namespace.h", <compat/include/time.h>, and <time.h>, but suppresses
the normal declaration of `time' in <time.h> by defining
__LIBC12_SOURCE__. Instead, <compat/include/time.h>
(src/lib/libc/compat/include/time.h) declares `time' with the
effective old signature:
int32_t time(int32_t *);
Then compat_time.c defines `time' normally:
time_t
time(time_t *t)
{
...
Again, macro expansion replaces `time' by `_time', but since there
is no __RENAME directive in <compat/include/time.h>, the resulting
ELF global symbol is `_time'.
Finally, alongside the definition in compat_time.c is
__weak_alias(time,_time)
to define `time' as an ELF weak symbol aliasing `_time'.
The net effect is that NetBSD 6's libc provides the same definitions
as NetBSD 5's libc for the symbols `time' and `_time', so that old
programs that were compiled in NetBSD 5 will continue to work with
NetBSD 6's libc. But programs compiled in NetBSD 6 will have 64-bit
time_t.

41
lib/libc/db/README
View File

@ -1,41 +0,0 @@
# $NetBSD: README,v 1.3 1996/05/03 21:17:07 cgd Exp $
# @(#)README 8.27 (Berkeley) 9/1/94
This is version 1.85 of the Berkeley DB code.
For information on compiling and installing this software, see the file
PORT/README.
Newer versions of this software will periodically be made available by
anonymous ftp from ftp.cs.berkeley.edu. An archive in compressed format
is in ucb/4bsd/db.tar.Z, or in gzip format in ucb/4bsd/db.tar.gz. If
you'd like to receive announcements of future releases of this software,
send email to the contact address below.
Email questions may be addressed to Keith Bostic at bostic@cs.berkeley.edu.
============================================
Distribution contents:
Makefile.inc Ignore this, it's the 4.4BSD subsystem Makefile.
PORT The per OS/architecture directories to use to build
libdb.a, if you're not running 4.4BSD. See the file
PORT/README for more information.
README This file.
btree The B+tree routines.
changelog List of changes, per version.
db The dbopen(3) interface routine.
docs Various USENIX papers, and the formatted manual pages.
hash The extended linear hashing routines.
man The unformatted manual pages.
mpool The memory pool routines.
recno The fixed/variable length record routines.
test Test package.
============================================
Debugging:
If you're running a memory checker (e.g. Purify) on DB, make sure that
you recompile it with "-DPURIFY" in the CFLAGS, first. By default,
allocated pages are not initialized by the DB code, and they will show
up as reads of uninitialized memory in the buffer write routines.

69
lib/libc/db/hash/README
View File

@ -1,69 +0,0 @@
# $NetBSD: README,v 1.5 1999/02/16 17:59:18 kleink Exp $
# @(#)README 8.1 (Berkeley) 6/4/93
This package implements a superset of the hsearch and dbm/ndbm libraries.
Test Programs:
All test programs which need key/data pairs expect them entered
with key and data on separate lines
tcreat3.c
Takes
bucketsize (bsize),
fill factor (ffactor), and
initial number of elements (nelem).
Creates a hash table named hashtest containing the
keys/data pairs entered from standard in.
thash4.c
Takes
bucketsize (bsize),
fill factor (ffactor),
initial number of elements (nelem)
bytes of cache (ncached), and
file from which to read data (fname)
Creates a table from the key/data pairs on standard in and
then does a read of each key/data in fname
tdel.c
Takes
bucketsize (bsize), and
fill factor (ffactor).
file from which to read data (fname)
Reads each key/data pair from fname and deletes the
key from the hash table hashtest
tseq.c
Reads the key/data pairs in the file hashtest and writes them
to standard out.
tread2.c
Takes
butes of cache (ncached).
Reads key/data pairs from standard in and looks them up
in the file hashtest.
tverify.c
Reads key/data pairs from standard in, looks them up
in the file hashtest, and verifies that the data is
correct.
NOTES:
The man page ../man/db.3 explains the interface to the hashing system.
The file hash.ps is a postscript copy of a paper explaining
the history, implementation, and performance of the hash package.
"bugs" or idiosyncracies
If you have a lot of overflows, it is possible to run out of overflow
pages. Currently, this will cause a message to be printed on stderr.
Eventually, this will be indicated by a return error code.
If you are using the ndbm interface and exit without flushing or closing the
file, you may lose updates since the package buffers all writes. Also,
the db interface only creates a single database file. To avoid overwriting
the user's original file, the suffix ".db" is appended to the file name
passed to dbm_open. Additionally, if your code "knows" about the historic
.dir and .pag files, it will break.
There is a fundamental difference between this package and the old hsearch.
Hsearch requires the user to maintain the keys and data in the application's
allocated memory while hash takes care of all storage management. The down
side is that the byte strings passed in the ENTRY structure must be null
terminated (both the keys and the data).

8
lib/libc/db/mpool/README
View File

@ -1,8 +0,0 @@
# $NetBSD: README,v 1.2 1995/02/27 13:24:00 cgd Exp $
# @(#)README 8.1 (Berkeley) 6/4/93
These are the current memory pool routines.
They aren't ready for prime time, yet, and
the interface is expected to change.
--keith

235
lib/libc/rpc/README
View File

@ -1,235 +0,0 @@
# $NetBSD: README,v 1.2 1998/01/09 04:11:52 perry Exp $
RPCSRC 4.0 7/11/89
This distribution contains Sun Microsystem's implementation of the
RPC and XDR protocols and is compatible with 4.2BSD and 4.3BSD. Also
included is complete documentation, utilities, RPC service
specification files, and demonstration services in the format used by
the RPC protocol compiler (rpcgen). See WHAT'S NEW below for
details.
NOTE ABOUT SECURE RPC:
This release of RPCSRC contains most of the code needed to implement
Secure RPC (see "DES Authentication" in the RPC Protocol Specification,
doc/rpc.rfc.ms). Due to legal considerations, we are unable to
distribute an implementation of DES, the Data Encryption Standard, which
Secure RPC requires. For this reason, all of the files, documentation, and
programs associated with Secure RPC have been placed into a separate
directory, secure_rpc. The RPC library contained in the main body of this
release *DOES NOT* support Secure RPC. See secure_rpc/README for more
details. (A DES library was posted in Volume 18 of comp.sources.unix.)
If you wish to report bugs found in this release, send mail to:
Portable ONC/NFS
Sun Microsystems, Inc
MS 12-33
2550 Garcia Avenue
Mountain View, CA 94043
or send Email to nfsnet@sun.com (the Internet) or sun!nfsnet (Usenet).
ROADMAP
The directory hierarchy is as follows:
demo/ Various demonstration services
demo/dir Remote directory lister
demo/msg Remote console message delivery service
demo/sort Remote sort service
doc/ Documentation for RPC, XDR and NFS in "-ms" format.
etc/ Utilities (rpcinfo and portmap). portmap must be
started by root before any other RPC network services are
used. SEE BELOW FOR BUGFIX TO 4.3BSD COMPILER.
man/ Manual pages for RPC library, rpcgen, and utilities.
rpc/ The RPC and XDR library. SEE BELOW
FOR BUGFIX TO 4.2BSD COMPILER.
rpcgen/ The RPC Language compiler (for .x files)
rpcsvc/ Service definition files for various services and the
server and client code for the Remote Status service.
secure_rpc/ The files in this directory are used to build a version of
the RPC library with DES Authentication. See the README
file in that directory for more details.
BUILD INSTRUCTIONS
Makefiles can be found in all directories except for man. The
Makefile in the top directory will cause these others to be invoked
(except for in the doc, man and demo directories), in turn building the
entire release.
WARNING! THE DEFAULT INSTALLATION PROCEDURES WILL INSTALL FILES
IN /usr/include, /usr/lib, /usr/bin and /etc.
The master RPC include file, rpc/rpc.h, is used by all programs and
routines that use RPC. It includes other RPC and system include files
needed by the RPC system. PLEASE NOTE: If your system has NFS, it
may have been based on Sun's NFS Source. The include files installed
by this package may duplicate include files you will find on your NFS
system. The RPCSRC 4.0 include files are upwardly compatible to all
NFS Source include files as of the date of this distribution (not
including any new definitions or declarations added by your system
vendor). HOWEVER: Please read the comments towards the end of
rpc/rpc.h regarding rpc/netdb.h. You may need to uncomment the
inclusion of that file if the structures it defines are already
defined by your system's include files.
After making any compiler fixes that are needed (see below), at
the top directory, type:
make install
For all installations, the Makefile macro DESTDIR is prepended to the
installation path. It is defined to be null in the Makefiles, so
installations are relative to root. (You will probably need root
privileges for installing the files under the default path.) To
install the files under some other tree (e.g., /usr/local), use the
command:
make install DESTDIR=/usr/local
This will place the include files in /usr/local/usr/include, the RPC
library in /usr/local/usr/lib, rpcgen in /usr/local/usr/bin, and the
utilities in /usr/local/etc. You'll have to edit the Makefiles or
install the files by hand if you want to do anything other than this
kind of relocation of the installation tree.
The RPC library will be built and installed first. By default it is
installed in /usr/lib as "librpclib.a". The directory
/usr/include/rpc will also be created, and several header files will
be installed there. ALL RPC SERVICES INCLUDE THESE HEADER FILES.
The programs in etc/ link in routines from librpclib.a. If you change
where it is installed, be sure to edit etc/'s Makefile to reflect this.
These programs are installed in /etc. PORTMAP MUST BE RUNNING ON
YOUR SYSTEM BEFORE YOU START ANY OTHER RPC SERVICE.
rpcgen is installed in /usr/bin. This program is required to build
the demonstration services in demo and the rstat client and server in
rpcsvc/.
The rpcsvc/ directory will install its files in the directory
/usr/include/rpcsvc. The Remote Status service (rstat_svc) will be
compiled and installed in /etc. If you wish to make this service
available, you should either start this service when needed or have
it started at boot time by invoking it in your /etc/rc.local script.
(Be sure that portmap is started first!) Sun has modified its
version of inetd to automatically start RPC services. (Use "make
LIB=" when building rstat on a Sun Workstation.) The Remote Status
client (rstat) will be installed in /usr/bin. This program queries
the rstat_svc on a remote host and prints a system status summary
similar to the one printed by "uptime".
The documentation is not built during the "make install" command.
Typing "make" in the doc directory will cause all of the manuals to
be formatted using nroff into a single file. We have had a report
that certain "troff" equivalents have trouble processing the full
manual. If you have trouble, try building the manuals individually
(see the Makefile).
The demonstration services in the demo directory are not built by the
top-level "make install" command. To build these, cd to the demo
directory and enter "make". The three services will be built.
RPCGEN MUST BE INSTALLED in a path that make can find. To run the
services, start the portmap program as root and invoke the service
(you probably will want to put it in the background). rpcinfo can be
used to check that the service succeeded in getting registered with
portmap, and to ping the service (see rpcinfo's man page). You can
then use the corresponding client program to exercise the service.
To build these services on a Sun workstation, you must prevent the
Makefile from trying to link the RPC library (as these routines are
already a part of Sun's libc). Use: "make LIB=".
BUGFIX FOR 4.3BSD COMPILER
The use of a 'void *' declaration for one of the arguments in
the reply_proc() procedure in etc/rpcinfo.c will trigger a bug
in the 4.3BSD compiler. The bug is fixed by the following change to
the compiler file mip/manifest.h:
*** manifest.h.r1.1 Thu Apr 30 13:52:25 1987
--- manifest.h.r1.2 Mon Nov 23 18:58:17 1987
***************
*** 21,27 ****
/*
* Bogus type values
*/
! #define TNULL PTR /* pointer to UNDEF */
#define TVOID FTN /* function returning UNDEF (for void) */
/*
--- 21,27 ----
/*
* Bogus type values
*/
! #define TNULL INCREF(MOETY) /* pointer to MOETY -- impossible type */
#define TVOID FTN /* function returning UNDEF (for void) */
/*
If you cannot fix your compiler, change the declaration in reply_proc()
from 'void *' to 'char *'.
BUGFIX FOR 4.2BSD COMPILER
Unpatched 4.2BSD compilers complain about valid C. You can make old
compilers happy by changing some voids to ints. However, the fix to
the 4.2 VAX compiler is as follows (to mip/trees.c):
*** trees.c.r1.1 Mon May 11 13:47:58 1987
--- trees.c.r1.2 Wed Jul 2 18:28:52 1986
***************
*** 1247,1253 ****
if(o==CAST && mt1==0)return(TYPL+TYMATCH);
if( mt12 & MDBI ) return( TYPL+LVAL+TYMATCH );
else if( (mt1&MENU)||(mt2&MENU) ) return( LVAL+NCVT+TYPL+PTMATCH+PUN );
! else if( mt12 == 0 ) break;
else if( mt1 & MPTR ) return( LVAL+PTMATCH+PUN );
else if( mt12 & MPTI ) return( TYPL+LVAL+TYMATCH+PUN );
break;
--- 1261,1269 ----
if(o==CAST && mt1==0)return(TYPL+TYMATCH);
if( mt12 & MDBI ) return( TYPL+LVAL+TYMATCH );
else if( (mt1&MENU)||(mt2&MENU) ) return( LVAL+NCVT+TYPL+PTMATCH+PUN );
! /* if right is TVOID and looks like a CALL, is not ok */
! else if (mt2 == 0 && (p->in.right->in.op == CALL || p->in.right->in.op == UNARY CALL))
! break;
else if( mt1 & MPTR ) return( LVAL+PTMATCH+PUN );
else if( mt12 & MPTI ) return( TYPL+LVAL+TYMATCH+PUN );
break;
WHAT'S NEW IN THIS RELEASE: RPCSRC 4.0
The previous release was RPCSRC 3.9. As with all previous releases,
this release is based directly on files from Sun Microsystem's
implementation.
Upgrade from RPCSRC 3.9
1) RPCSRC 4.0 upgrades RPCSRC 3.9. Improvements from SunOS 4.0 have
been integrated into this release.
Secure RPC (in the secure_rpc/ directory)
2) DES Authentication routines and programs are provided.
3) A new manual, "Secure NFS" is provided, which describes Secure RPC
and Secure NFS.
4) Skeleton routines and manual pages are provided which describe the
DES encryption procedures required by Secure RPC. HOWEVER, NO DES
ROUTINE IS PROVIDED.
New Functionality
5) rpcinfo can now be used to de-register services from the portmapper
which may have terminated abnormally.
6) A new client, rstat, is provided which queries the rstat_svc and
prints a status line similar to the one displayed by "uptime".

8
lib/libc/softfloat/README.NetBSD
View File

@ -1,8 +0,0 @@
$NetBSD: README.NetBSD,v 1.2 2002/05/21 23:51:05 bjh21 Exp $
This is a modified version of part of John Hauser's SoftFloat 2a package.
This version has been heavily modified to support its use with GCC to
implement built-in floating-point operations, but compiling
softfloat.c without SOFTFLOAT_FOR_GCC defined should get you the same
results as from the original.

39
lib/libc/softfloat/README.txt
View File

@ -1,39 +0,0 @@
$NetBSD: README.txt,v 1.1 2000/06/06 08:15:02 bjh21 Exp $
Package Overview for SoftFloat Release 2a
John R. Hauser
1998 December 13
SoftFloat is a software implementation of floating-point that conforms to
the IEC/IEEE Standard for Binary Floating-Point Arithmetic. SoftFloat is
distributed in the form of C source code. Compiling the SoftFloat sources
generates two things:
-- A SoftFloat object file (typically `softfloat.o') containing the complete
set of IEC/IEEE floating-point routines.
-- A `timesoftfloat' program for evaluating the speed of the SoftFloat
routines. (The SoftFloat module is linked into this program.)
The SoftFloat package is documented in four text files:
softfloat.txt Documentation for using the SoftFloat functions.
softfloat-source.txt Documentation for compiling SoftFloat.
softfloat-history.txt History of major changes to SoftFloat.
timesoftfloat.txt Documentation for using `timesoftfloat'.
Other files in the package comprise the source code for SoftFloat.
Please be aware that some work is involved in porting this software to other
targets. It is not just a matter of getting `make' to complete without
error messages. I would have written the code that way if I could, but
there are fundamental differences between systems that I can't make go away.
You should not attempt to compile SoftFloat without first reading both
`softfloat.txt' and `softfloat-source.txt'.
At the time of this writing, the most up-to-date information about
SoftFloat and the latest release can be found at the Web page `http://
HTTP.CS.Berkeley.EDU/~jhauser/arithmetic/SoftFloat.html'.

31
lib/libm/arch/m68060/Readme.NetBSD
View File

@ -1,31 +0,0 @@
- Import new Motorola 060SP packages in /sys/arch/m68k/060SP first.
- if you had to change something in here, "make clean" here
- commit Makefile Readme.NetBSD makeas.sh makeoffs.awk
- "make" here
- commit this directory
----------------------------------------------------------------------
Method:
Out of the table, we create a wrapper for fplsp.S. It contains:
Single precision:
movl sp@(4),sp@- 4
bsr _060fplsp+theoffset 4
fmovs fp0,sp@ 4
movel sp@+,d0 4
rts 2
(18 bytes)
Double precision:
movl sp@(4+0),sp@- 4
movl sp@(8+4),sp@- 4
bsr _060fplsp+theoffset 4
fmovd fp0,sp@ 4
movel sp@+,d0 4
movel sp@+,d1 4
rts 2
(26 bytes)
For __SVR4_ABI, the code is much shorter... it reduces to a single jbra.

64
minix/drivers/bus/i2c/README.txt
View File

@ -1,64 +0,0 @@
Minix i2c Driver
================
TODO: this probably belongs on the wiki
Overview
--------
This is the driver for the i2c bus. It provides the same /dev interface as
NetBSD and OpenBSD (see dev/i2c/i2c_io.h). It also provides an interface for
other drivers to access the I2C bus using Minix IPC.
Organization and Layout
-----------------------
i2c.c generic i2c bus driver
arch/ arch specific code
earm/ earm specific code
omap_i2c.c AM335X/DM37XX i2c bus driver
omap_i2c.h AM335X/DM37XX function prototypes
omap_i2c_registers.h AM335X/DM37XX register offsets, etc.
Testing the Code
----------------
Below are the steps needed to start up the i2c driver instances. Though,
now they get started at boot in /usr/etc/rc, it's still useful to know if
you take down the service and need to start it again.
Creating the device files (this is already done automatically, but if not):
cd /dev && MAKEDEV i2c-1 && MAKEDEV i2c-2 && MAKEDEV i2c-3
Starting up the instances:
/sbin/minix-service up /service/i2c -dev /dev/i2c-1 -label i2c.1 -args instance=1
/sbin/minix-service up /service/i2c -dev /dev/i2c-2 -label i2c.2 -args instance=2
/sbin/minix-service up /service/i2c -dev /dev/i2c-3 -label i2c.3 -args instance=3
There is an i2cscan program from NetBSD which can detect devices on the bus:
i2cscan -r /dev/i2c-1
i2cscan -r /dev/i2c-2
i2cscan -r /dev/i2c-3
Limitations
-----------
The i2c controllers used in the am335x and the dm37xx do not support zero
byte transfers. Writing 0 bytes is a common method used to probe the bus
for devices. Most of the address ranges i2cscan scans are done by this
method. Therefore, only a subset of devices on the bus will be detected by
i2cscan (i.e. the devices it detects using the 1 byte read method). See
the register description for I2C_CNT in the technical reference manuals
for details about why 0 byte transfers are not allowed.
Developing I2C Device Drivers
-----------------------------
The driver for the EEPROM (a.k.a. drivers/cat24c256) is the hello world of
Minix i2c device drivers. It shows how to use the i2cdriver library and
how to use the bus for reads and writes. commands/eepromread is another
place to look if you're interested in accessing devices through the /dev
interface.

122
share/misc/NetBSD.el
View File

@ -1,122 +0,0 @@
;; $NetBSD: NetBSD.el,v 1.6 2009/02/16 21:37:12 uwe Exp $
(defconst netbsd-knf-style
'(
;; (c-auto-newline . nil)
;; default indentation level
(c-basic-offset . 8)
;; in which column to add backslashes when macroizing a region
(c-backslash-column . 78)
(c-backslash-max-column . 78)
;; automatically compact brace-else(if)-brace on one line and
;; semi-colon after closing struct brace
(c-cleanup-list . (brace-else-brace
brace-elseif-brace
defun-close-semi))
;; do not indent lines containing only start-of-comment more than default
(c-comment-only-line-offset . 0)
;; start new lines after braces
;; default is: before and after (for all other cases)
(c-hanging-braces-alist . ((defun-open . (before after))
(defun-close . (before after))
(block-open . (after))
(block-close . c-snug-do-while)
(substatement-open . after)
(statement-case-open . nil)
(brace-list-open . after)
(brace-list-close . nil)
))
;; where to put newlines around colons
(c-hanging-colons-alist . (quote ((label after)
(case-label after))))
;; indent comments syntactically
(c-indent-comments-syntactically-p . t)
;; no spaces needed before a label
;; (c-label-minimum-indentation . 0)
;; define offsets for some code parts
(c-offsets-alist . ((arglist-cont-nonempty . 4)
(block-open . 0)
;; (block-open . -)
(brace-list-open . +)
(brace-list-intro . +)
(brace-list-entry . 0)
(brace-list-close . 0)
(knr-argdecl . 0)
(knr-argdecl-intro . +)
(label . -)
(member-init-intro . ++)
(statement-cont . 4)
(substatement-open . 0)
(case-label . 0)))
;; XXX: undocumented. Recognize KNR style?
(c-recognize-knr-p . t)
;; indent line when pressing tab, instead of a plain tab character
(c-tab-always-indent . t)
;; use TABs for indentation, not spaces
(indent-tabs-mode . t)
;; set default tab width to 8
(tab-width . 8)
)
"NetBSD KNF Style")
(eval-when-compile (require 'whitespace nil t))
(defcustom netbsd-knf-whitespace-check nil
"Enable NetBSD KNF whitespace cleanup when saving the buffer.
See also:
`whitespace-auto-cleanup',
`whitespace-abort-on-error',
`whitespace-check-leading-whitespace',
`whitespace-check-trailing-whitespace',
`whitespace-check-spacetab-whitespace',
`whitespace-check-indent-whitespace',
`whitespace-check-ateol-whitespace'.
NOTES:
1) `whitespace-check-spacetab-whitespace' will replace any RE-match of
\" +\\t\" with single '\\t' and hence may break tabbing.
2) Both `whitespace-check-spacetab-whitespace' and
`whitespace-check-indent-whitespace' may alter strings."
:type 'boolean
:group 'netbsd-knf)
(defun netbsd-knf-whitespace-cleanup ()
;; XXX - emacs 21.4 whitespace.el was badly behaved on blank
;; buffers. This was fixed in 22.1. I don't know about other
;; versions, so these conditions may need to be more restrictive.
(cond ((> emacs-major-version 21)
(whitespace-cleanup-internal))
(t ;; default
(if (save-excursion
(goto-char (point-min))
(re-search-forward "[^ \t\n]" nil t))
(whitespace-cleanup)
(delete-region (point-min) (point-max))))))
(defun netbsd-knf-write-contents-hook ()
(if (and (string-equal c-indentation-style "netbsd knf")
(require 'whitespace nil t))
(if netbsd-knf-whitespace-check
(if whitespace-auto-cleanup
(netbsd-knf-whitespace-cleanup)
(if (and (whitespace-buffer) whitespace-abort-on-error)
(error (concat "Abort write due to whitespaces in "
buffer-file-name)))))
(remove-hook 'write-contents-hook 'netbsd-knf-write-contents-hook))
nil)
(defun netbsd-knf-c-mode-hook ()
;; Add style and set it for current buffer
(c-add-style "NetBSD KNF" netbsd-knf-style t)
;; useful, but not necessary for the mode
;; give syntactic information in message buffer
;;(setq c-echo-syntactic-information-p t)
;; automatic newlines after special characters
(setq c-toggle-auto-state 1)
;; delete all connected whitespace when pressing delete
(setq c-toggle-hungry-state 1)
;; auto-indent new lines
(define-key c-mode-base-map "\C-m" 'newline-and-indent)
;; check/cleanup whitespace when saving
(add-hook 'write-contents-hooks 'netbsd-knf-write-contents-hook))
(add-hook 'c-mode-hook 'netbsd-knf-c-mode-hook)

2032
share/mk/bsd.README
View File

File diff suppressed because it is too large Load Diff

79
sys/arch/README
View File

@ -1,79 +0,0 @@
$NetBSD: README,v 1.62 2014/03/31 11:25:48 martin Exp $
acorn26 arm 20000509 Acorn ARM2- and ARM3-based machines
acorn32 arm 20011118 Acorn computers Ltd. ARM 6/7/SA based machines
algor mipsel,mips64el 20010528 Algorithmics, Ltd. MIPS evaluation boards
alpha alpha 19950213 Compaq (formerly Digital Equipment Corp.) Alpha
amd64 x86_64 20010619 AMD's x86 64 bit architecture
amiga m68k 19930902 Commodore et al. Amiga
amigappc powerpc 20000525 Phase 5 Amiga
arc mipsel,mips64el 20000123 MIPS Advanced Risc Computing spec machines
atari m68k 19950326 Atari TT30, Falcon, and Hades
bebox powerpc 19971014 Be Inc. BeBox
cats arm 19981005 Chalice Technologies, CATS motherboard
cesfic m68k 20010514 FIC8234 VME processor board
cobalt mipsel,mips64el 20000319 Cobalt Networks Microservers
dreamcast sh3el 20010107 SEGA Dreamcast
emips mipseb 20110126 Machines based on Extensible MIPS
epoc32 arm 20130502 32bit EPOC OS machines
evbarm armeb 20010905 ARM-based eval boards
evbmips mipseb,mipsel,mips64eb,mips64el 20020307 MIPS-based eval boards
evbppc powerpc,powerpc64 20021209 PowerPC-based eval boards
evbsh3 sh3eb,sh3el 20010206 Hitachi SuperH(TM) sh3 and sh4 eval boards
ews4800mips mipseb 20051229 NEC's MIPS based EWS4800 workstations
hp300 m68k 19930512 Hewlett Packard 300- and 400-series machines
hppa hppa 20020606 Hewlett Packard 700-series machines
hpcarm arm 20010220 ARM based handheld PCs
hpcmips mipsel 19990925 MIPS based handheld PCs
hpcsh sh3el 20010117 Hitachi SuperH(TM) based handheld PCs
i386 i386 19930321 Intel/AMD etc. x86 processor line
ia64 ia64 00000000 Intel Itanium/Itanium2 processor based workstations
ibmnws powerpc 00000000 IBM Network Station Thin Clients
iyonix arm 20040713 Castle Technology xscale based workstations
landisk sh3el 20060901 SH4 processor based NAS appliances by I-O DATA
luna68k m68k 20000105 LUNA product line of OMRON Tateisi Electronics
mac68k m68k 19930929 Apple Macintosh
macppc powerpc,powerpc64 19980515 Apple Power Macintosh and clones
mipsco mipseb 20000812 MIPS Corp Magnum 3000 computers
mmeye sh3eb 19990913 Hitachi SuperH(TM) computer controlled camera
mvme68k m68k 19950725 Motorola's VMEbus 68K based single board computers
mvmeppc powerpc 20020227 Motorola's PowerPC machines running older PPCBUG
netwinder arm 20010609 StrongARM based Netwinder machines
news68k m68k 19991209 Sony's m68k based NET WORK STATION
newsmips mipseb 19980218 Sony's MIPS based NET WORK STATION
next68k m68k 19980609 NeXT Computer's cubes and slabs
ofppc powerpc,powerpc64 19980528 Open Firmware based PowerPC machines
playstation2 mipsel 20011016 Sony PlayStation 2
pmax mipsel,mips64el 19931012 Digital Equipment Corp. MIPS based machines
prep powerpc 20000229 PowerPC Reference Platform machines
rs6000 powerpc 20071217 MCA-based IBM RS/6000 wokstations
sandpoint powerpc 20010211 Motorola Sandpoint based NAS systems
sbmips mipseb,mipsel,mips64eb,mips64el 20020306 Broadcom's SiByte processor evaluation boards
sgimips mipseb,mips64eb 20000614 MIPS based Silicon Graphics machines
shark arm 19960131 Digital Network Appliance Reference Design ("Shark")
sparc sparc 19931002 Sun Microsystems SPARC (sun4, sun4c, sun4m) 32 bit machines
sparc64 sparc64/sparc 19980620 Sun Microsystems UltraSPARC 64 bit machines
sun2 m68000 20010328 Sun m68010 based machines
sun3 m68k 19930625 Sun m680[23]0 based machines
vax vax 19940802 Digital Equipment Corp. VAX machines
x68k m68k 19960505 Sharp X68000, X68030
xen xen 20040311 Xen virtual machine monitor
zaurus arm 20061217 Sharp Zaurus C7x0/860/1000/3x00 PDAs
Generic cpu features shared among multiple ports
arm: ARM CPU based platform files
hppa: Hewlett Packard PA-RISC CPU based platform files
m68k: Motorola 680x0 CPU based platform files
mips: MIPS CPU based platform files
powerpc: PowerPC CPU based platform files
sh3: Hitachi SuperH(TM) sh3 and sh4 CPU based platform files
sparc: Sun Microsystems SPARC(TM) CPU based platform files
x86: Intel x86 based platform files.
Generic architectural features shared among multiple ports
hpc: Handheld PC reference platform files
sun68k: Sun Microsystems Motorola 680x0 CPU based platform files
Single port cpu families
alpha: Digital Equipment Alpha processor
ia64: Intel Itanium/Itanium2 processor

137
sys/ufs/lfs/README
View File

@ -1,137 +0,0 @@
# $NetBSD: README,v 1.3 1999/03/15 00:46:47 perseant Exp $
# @(#)README 8.1 (Berkeley) 6/11/93
The file system is reasonably stable...I think.
For details on the implementation, performance and why garbage
collection always wins, see Dr. Margo Seltzer's thesis available for
anonymous ftp from toe.cs.berkeley.edu, in the directory
pub/personal/margo/thesis.ps.Z, or the January 1993 USENIX paper.
----------
The disk is laid out in segments. The first segment starts 8K into the
disk (the first 8K is used for boot information). Each segment is composed
of the following:
An optional super block
One or more groups of:
segment summary
0 or more data blocks
0 or more inode blocks
The segment summary and inode/data blocks start after the super block (if
present), and grow toward the end of the segment.
_______________________________________________
| | | | |
| summary | data/inode | summary | data/inode |
| block | blocks | block | blocks | ...
|_________|____________|_________|____________|
The data/inode blocks following a summary block are described by the
summary block. In order to permit the segment to be written in any order
and in a forward direction only, a checksum is calculated across the
blocks described by the summary. Additionally, the summary is checksummed
and timestamped. Both of these are intended for recovery; the former is
to make it easy to determine that it *is* a summary block and the latter
is to make it easy to determine when recovery is finished for partially
written segments. These checksums are also used by the cleaner.
Summary block (detail)
________________
| sum cksum |
| data cksum |
| next segment |
| timestamp |
| FINFO count |
| inode count |
| flags |
|______________|
| FINFO-1 | 0 or more file info structures, identifying the
| . | blocks in the segment.
| . |
| . |
| FINFO-N |
| inode-N |
| . |
| . |
| . | 0 or more inode daddr_t's, identifying the inode
| inode-1 | blocks in the segment.
|______________|
Inode blocks are blocks of on-disk inodes in the same format as those in
the FFS. However, spare[0] contains the inode number of the inode so we
can find a particular inode on a page. They are packed page_size /
sizeof(inode) to a block. Data blocks are exactly as in the FFS. Both
inodes and data blocks move around the file system at will.
The file system is described by a super-block which is replicated and
occurs as the first block of the first and other segments. (The maximum
number of super-blocks is MAXNUMSB). Each super-block maintains a list
of the disk addresses of all the super-blocks. The super-block maintains
a small amount of checkpoint information, essentially just enough to find
the inode for the IFILE (fs->lfs_idaddr).
The IFILE is visible in the file system, as inode number IFILE_INUM. It
contains information shared between the kernel and various user processes.
Ifile (detail)
________________
| cleaner info | Cleaner information per file system. (Page
| | granularity.)
|______________|
| segment | Space available and last modified times per
| usage table | segment. (Page granularity.)
|______________|
| IFILE-1 | Per inode status information: current version #,
| . | if currently allocated, last access time and
| . | current disk address of containing inode block.
| . | If current disk address is LFS_UNUSED_DADDR, the
| IFILE-N | inode is not in use, and it's on the free list.
|______________|
First Segment at Creation Time:
_____________________________________________________________
| | | | | | | |
| 8K pad | Super | summary | inode | ifile | root | l + f |
| | block | | block | | dir | dir |
|________|_______|_________|_______|_______|_______|_______|
^
Segment starts here.
Some differences from the Sprite LFS implementation.
1. The LFS implementation placed the ifile metadata and the super block
at fixed locations. This implementation replicates the super block
and puts each at a fixed location. The checkpoint data is divided into
two parts -- just enough information to find the IFILE is stored in
two of the super blocks, although it is not toggled between them as in
the Sprite implementation. (This was deliberate, to avoid a single
point of failure.) The remaining checkpoint information is treated as
a regular file, which means that the cleaner info, the segment usage
table and the ifile meta-data are stored in normal log segments.
(Tastes great, less filling...)
2. The segment layout is radically different in Sprite; this implementation
uses something a lot like network framing, where data/inode blocks are
written asynchronously, and a checksum is used to validate any set of
summary and data/inode blocks. Sprite writes summary blocks synchronously
after the data/inode blocks have been written and the existence of the
summary block validates the data/inode blocks. This permits us to write
everything contiguously, even partial segments and their summaries, whereas
Sprite is forced to seek (from the end of the data inode to the summary
which lives at the end of the segment). Additionally, writing the summary
synchronously should cost about 1/2 a rotation per summary.
3. Sprite LFS distinguishes between different types of blocks in the segment.
Other than inode blocks and data blocks, we don't.
4. Sprite LFS traverses the IFILE looking for free blocks. We maintain a
free list threaded through the IFILE entries.
5. The cleaner runs in user space, as opposed to kernel space. It shares
information with the kernel by reading/writing the IFILE and through
cleaner specific system calls.

20
tests/README
View File

@ -1,20 +0,0 @@
$NetBSD: README,v 1.4 2012/05/18 15:36:21 jruoho Exp $
When adding new tests, please try to follow the following conventions.
1. For library routines, including system calls, the directory structure of
the tests should follow the directory structure of the real source tree.
For instance, interfaces available via the C library should follow:
src/lib/libc/gen -> src/tests/lib/libc/gen
src/lib/libc/sys -> src/tests/lib/libc/sys
...
2. Equivalently, all tests for userland utilities should try to follow their
location in the source tree. If this can not be satisfied, the tests for
a utility should be located under the directory to which the utility is
installed. Thus, a test for env(1) should go to src/tests/usr.bin/env.
Likewise, a test for tcpdump(8) should be in src/tests/usr.sbin/tcpdump,
even though the source code for the program is located under src/external.
3. Otherwise use your own discretion.

66
tests/lib/libc/db/README
View File

@ -1,66 +0,0 @@
# $NetBSD: README,v 1.1 2011/01/07 15:05:58 pgoyette Exp $
# @(#)README 8.8 (Berkeley) 7/31/94
Fairly large files (the command files) are built in this directory during
the test runs, and even larger files (the database files) are created in
"/var/tmp". If the latter directory doesn't exist, set the environmental
variable TMPDIR to a directory where the files can be built.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The script file consists of lines with an initial character which is
the command for that line, or an initial character indicating a key
or data entry for a previous command.
Legal command characters are as follows:
c: compare a record
+ must be followed by [kK][dD]; the data value in the database
associated with the specified key is compared to the specified
data value.
e: echo a string
+ writes out the rest of the line into the output file; if the
last character is not a carriage-return, a newline is appended.
f: set the flags for the next command
+ no value zero's the flags
g: do a get command
+ must be followed by [kK]
+ writes out the retrieved data DBT.
o [r]: dump [reverse]
+ dump the database out, if 'r' is set, in reverse order.
p: do a put command
+ must be followed by [kK][dD]
r: do a del command
+ must be followed by [kK] unless R_CURSOR flag set.
S: sync the database
s: do a seq command
+ must be followed by [kK] if R_CURSOR flag set.
+ writes out the retrieved data DBT.
Legal key/data characters are as follows:
D [file]: data file
+ set the current data value to the contents of the file
d [data]:
+ set the current key value to the contents of the line.
K [file]: key file
+ set the current key value to the contents of the file
k [data]:
+ set the current key value to the contents of the line.
Blank lines, lines with leading white space, and lines with leading
hash marks (#) are ignored.
Options to dbtest are as follows:
-d: Set the DB_LOCK flag.
-f: Use the file argument as the database file.
-i: Use the rest of the argument to set elements in the info
structure. If the type is btree, then "-i cachesize=10240"
will set BTREEINFO.cachesize to 10240.
-o: The rest of the argument is the output file instead of
using stdout.
-s: Don't delete the database file before opening it, i.e.
use the database file from a previous run.
Dbtest requires two arguments, the type of access "hash", "recno"
or "btree", and the script name or "-" to indicate stdin.

147
tools/README
View File

@ -1,147 +0,0 @@
$NetBSD: README,v 1.4 2015/01/03 13:20:11 apb Exp $
Notes for NetBSD src/tools
Background
==========
Several programs that are part of NetBSD are also built as tools. Such
programs are typically built twice: once as a tool and once as part of
the release build. Tools are relevant only when the make(1) variable
USETOOLS=yes, which is the default for most NetBSD builds.
Tools are built on the host platform, using the host compiler,
and will run on the host platform during the cross-build of the
remainder of NetBSD. They are built near the beginning of a NetBSD
build (e.g. "build.sh tools" or "make tools" from the top level src
directory), and installed in ${TOOLDIR}.
Tools are executed during the main part of the build, when several
TOOL_* variables defined in src/share/mk/bsd.*.mk will refer to the
tools installed in ${TOOLDIR}.
Portability
===========
Programs that are built as tools need to be more portable than other
parts of NetBSD, because they will need to run on the host platform.
Most tools should restrict themselves to C language features that are
defined in C89 (ISO 9899-1989); they should avoid using C99 language
features. There are a few tools, such as compilers, where it is not
practical for the C89 restriction to be maintained. There are also a
few features, such as the long long data type, that are used by many
tools despite not being defined in C89.
Tools may use library features such as functions, macros, and
types, that are defined in C89 and in POSIX (IEEE Std 1003.1) (XXX
year?), and features that are provided by the compatibility framework
(src/tools/compat) described in a separate section below. This is
usually not an onerous burden, because many C99 library features, and
NetBSD-specific features, are already provided by src/tools/compat, or
can be added when the need for them becomes apparent.
If a tool attempts to use a feature that is not available on the host
platform, then the tools build will fail. This can be addressed by
changing the tool to avoid that feature, or by adding the feature to the
src/tools/compat framework. It is usually easy to add new macros or
functions to src/tools/compat, and that is usually better than adding
compatibility definitions to individual tools.
Compatibility framework
=======================
src/tools/compat provides a compatibility framework for use by tools.
It installs the following components, and more:
${TOOLDIR}/lib/libnbcompat.a
A library containing functions that are needed by some tools.
${TOOLDIR}/include/nbtool_compat.h
A header file defining macros that are needed by some tools.
${TOOLDIR}/share/compat/defs.mk
A makefile fragment, to be included by other makefiles,
to define make variables appropriate for building tools.
Among other things, this makefile fragment automatically adds
the libnbcompat.a library to the LDADD and DPADD variables,
so that tools will be linked with that library, and adds
-I${NETBSDSRCDIR}/tools/compat and -DHAVE_NBTOOL_CONFIG_H=1 to the
HOST_CPPFLAGS variable, so that compiled programs can detect when
they are being built as tools.
Adapting Makefiles for use with tools
=====================================
Makefiles under src/tools/*/Makefile should define the HOSTPROG
variable. This is typically done by tools/Makefile.hostprog,
which is directly or indirectly included by all Makefiles in
src/tools/*/Makefile.
Makefiles in the non-tools part of the src tree can test whether or not
the HOSTPROG variable is defined, in order tell the difference between
building a tool and building part of a NetBSD release, and they may
alter their behavior accordingly.
For example, the Makefile may conditionally refrain from compiling and
linking certain files, and the Makefile may conditionally pass macros to
the compiler via constructs like this:
.if defined(HOSTPROG)
CPPFLAGS+= -DWITH_FEATURE_X=0 # exclude feature X from tools build
.else
CPPFLAGS+= -DWITH_FEATURE_X=1 # include feature X in release build
.endif
Adapting Programs for use with tools
====================================
When a tool is being built, the C compiler should automatically be
invoked with -DHAVE_NBTOOL_CONFIG_H=1. This is done as a result of
settings in ${TOOLDIR}/share/compat/defs.mk, which should be included
from src/tools/Makefile.host, which should be included directly or
indirectly from src/tools/*/Makefile.
A C source file can test whether the HAVE_NBTOOL_CONFIG_H macro is
defined, in order to tell whether or not it is being compiled as part of
a tool.
In order to obtain the definitions provided by the tools compatibility
framework, almost every C source file that is built as part of a tool
should have lines like these as the first non-comment lines:
#if HAVE_NBTOOL_CONFIG_H
#include "nbtool_config.h"
#endif
To omit features from the tools version of a program, the program
may test the HAVE_NBTOOL_CONFIG_H macro, like this:
#if HAVE_NBTOOL_CONFIG_H
... code to be used when built as a tool
#else
... code to be used when built as part of a release
#endif
It is often preferable to use macros whose names refer to the features
that should be included or omitted. See the section on "Adapting
Makefiles for use with tools" for an example in which the Makefile
passes -DWITH_FEATURE_X=0 or -DWITH_FEATURE_X=1 to the compiler
according to whether or not the program is being built as a tool. Then
the program can use code like this:
#if WITH_FEATURE_X
... code to be used when FEATURE X is desired,
... e.g. when being built as part of a release.
#else
... code to be used when FEATURE X is not desired,
... e.g. when being built as a tool.
#endif

87
tools/compat/README
View File

@ -1,87 +0,0 @@
$NetBSD: README,v 1.12 2005/04/05 00:21:22 jmc Exp $
Special notes for cross-hosting a NetBSD build on certain platforms.
Only those platforms which have been tested to complete a "build.sh" run
are listed.
All hosts must have a POSIX compatible sh. /bin/sh is assumed unless
otherwise set. This can be overridden by setting HOST_SH in the environment.
In addition all hosts must provide the following local tools:
gzip
=====
NetBSD:
* _NETBSD_SOURCE is *not* to be defined/pulled in during compat/tools builds.
compat_defs.h will error out if it finds it defined.
HP-UX:
* zlib must be available.
This will be fixed in the future to include zlib in libnbcompat.
=====
LINUX:
* Tested on RedHat Linux 7.1 (i386).
Tested on RedHat Linux 7.3 (i686) on 16 Sep 2002. Requires "LANG=C"
in the environment.
* Tested on Redhat Linux 8.0 (i686) in Fall 2003. Requires no special settings.
* Tested on Redhat ES3 and AS3 in spring of 2004. Requires no special settings.
* The gcc (and libstdc++, if needed) package must be installed, along
with the typical system development packages (glibc-devel, etc.).
* The ncurses-devel package must be installed (for nbinfo).
* The zlib and zlib-devel packages must be installed. This will be
fixed in the future to include zlib in libnbcompat.
=====
MACOS
Requires a case sensitive filesystem such as UFS
* Tested on 10.2.8 with Dec 2002 Developer Tools
- may require a fix to /usr/bin/join, netbsd's join should work fine
* Tested on 10.3 with xcode 1.5
- compiles fine out of the box
=====
NETBSD (earlier releases):
* Tested on NetBSD 1.5.2 (machine-independently).
* Should need no special setup.
=====
SOLARIS:
* Tested on Solaris/x86 8 (5.8) with gcc 2.95.2 and Solaris/sparc 8 (5.8)
with gcc 3.2 (not yet tested with SUNWspro).
* $HOST_CC needs to be set properly (for gcc, it should be set to "gcc",
otherwise the improper /usr/ucb/cc may be invoked by accident).
* The SUNWzlib package (or a built version of zlib visible to $HOST_CC,
such as SMCzlib from sunfreeware.com) must be installed. This will be
fixed in the future to include zlib in libnbcompat.
* Needs the following paths, in this order, in $PATH:
/usr/xpg4/bin
/usr/ccs/bin
<path to host C and C++ compilers>
/usr/bin
/usr/ucb may optionally be placed before /usr/bin, per your preference,
but /usr/ucb *MUST NOT* be before /usr/ccs/bin or before the path to
the host C and C++ compilers.

84
tools/gcc/README.mknative
View File

@ -1,84 +0,0 @@
$NetBSD: README.mknative,v 1.20 2014/06/14 20:49:37 mrg Exp $
This file describes how to bootstrap the native toolchain on a new NetBSD
platform (and how to update the new toolchain files, if needed). These
files may be generated on a cross-compile host without problems.
NOTE: DO NOT RUN "mknative" BY HAND! It requires the Makefile in this
directory to set up certain environments first.
Since libc's features change over time, the config.h files can change as a
result; thus the instructions below are the same no matter whether
bootstrapping on a cross or native host. This is important: even on a
"native" host, you should bootstrap the toolchain by building from an
up-to-date source tree to a $DESTDIR using the exact same instructions.
In these notes, MACHINE is the $MACHINE of the target. These files can be
cross-generated. Though a $MACHINE_ARCH all uses the same config files, you
must pick a specific $MACHINE so that building the requisite bits below will
work.
0. Note that example paths like src/external/gpl3/gcc/lib/libgcc/arch will
really be src/external/gpl3/gcc.old/lib/libgcc/arch for the previous GCC.
1. Set MKMAINTAINERTOOLS=yes in mk.conf. (Needed so that src/tools/gettext
gets built, eliciting proper HAVE_*GETTEXT* defns in config.h files.)
2. Build and install a cross toolchain (via "build.sh -m MACHINE tools").
Note that while PR #47353 is not fixed, you can not use the -O option
to build.sh. Use -M instead. (The differences are in layout and pathname
prefixes in the object directory pointed to by each option.)
3. In src/tools/gcc, do "nbmake-MACHINE HAVE_GCC=48 bootstrap-libgcc".
This will create just enough glue in src/external/gpl3/gcc/lib/libgcc/arch
to make it possible to build, based on the toolchain built in
${.OBJDIR}/build.
Because the files generated in this step contain things like
-DCROSS_COMPILE, they are not suitable for committing. Step 8 below
will regenerate the "proper" libgcc config files.
4. At top level, do
"nbmake-MACHINE obj do-distrib-dirs MKGCC=no MKBINUTILS=no HAVE_GCC=48", and
"nbmake-MACHINE includes HAVE_GCC= MKGCC=no MKBINUTILS=no HAVE_GCC=48".
(Note: replace 48 [for gcc 4.8.x] with the appropriate version you are
going to mknative-for, the MKGCC=no prevents the standard makefiles from
picking up any gcc version info automatically)
5. In src/lib/csu, do
"nbmake-MACHINE dependall". and "nbmake-MACHINE install".
6. In src/external/gpl3/gcc/lib/libgcc, do
"nbmake-MACHINE obj includes dependall install".
7. In each of src/external/lgpl3/gmp/lib/libgmp,
src/external/lgpl3/mpfr/lib/libmpfr, src/external/lgpl3/mpc/lib/libmpc
do "nbmake-MACHINE obj dependall".
8. In src/lib, do
"nbmake-MACHINE dependall install MKGCC=no HAVE_GCC=48".
Optionally, all of the following may be set in the environment to reduce
the amount of code needed to build at this step. Basically, it must be
possible for static binaries to build and base system libs to exist so
that "configure" can do its job for the target--these MK* options omit
the rest for this stage of the build.
MKCRYPTO=no
MKLINT=no
MKPROFILE=no
MKSHARE=no
MKRUMP=no
9. In src/tools/gcc, do "nbmake-MACHINE native-gcc".
This will do a full configury in ${.OBJDIR}/.native that is a "Canadian"
cross toolchain (--build reflects the host platform, but --host and
--target are the target). The result is a tree that would build a
native-to-NetBSD compiler on a cross host, and mknative pulls glue data
from this.
10. Try out a full build using "nbmake-MACHINE"; the result should include
a native compiler.
11. If all is well, commit the glue files added to src/gnu/{lib,usr.bin}/*.

18
usr.bin/units/README
View File

@ -1,18 +0,0 @@
# $NetBSD: README,v 1.2 1996/04/06 06:00:59 thorpej Exp $
This is a program which I wrote as a clone of the UNIX 'units'
command. I threw it together in a couple days, but it seems to work,
with some restrictions. I have tested it under DOS with Borland C and
Ultrix 4.2, and SunOS 4.1.
This program differs from the unix units program in the following
ways:
it can gracefully handle exponents larger than 9 in output
it uses 'e' to denote exponentiation in numbers
prefixes are listed in the units file
it tries both -s and -es plurals
it allows use of * for multiply and ^ for exponentiation in the input
the output format is somewhat different
Adrian Mariano (adrian@cam.cornell.edu or mariano@geom.umn.edu)

135
usr.sbin/makefs/README
View File

@ -1,135 +0,0 @@
$NetBSD: README,v 1.7 2015/01/12 19:50:47 christos Exp $
makefs - build a file system image from a directory tree
NOTES:
* This tool uses modified local copies of source found in other
parts of the tree. This is intentional.
* makefs is a work in progress, and subject to change.
user overview:
--------------
makefs creates a file system image from a given directory tree.
the following file system types can be built:
cd9660 ISO 9660 file system
chfs "Chip" file system, for flash devices
ffs BSD fast file system
msdos MS-DOS `FAT' file system (FAT12, FAT16, FAT32)
udf Universal Disk Format file system
v7fs 7th edition(V7) file system
Support for the following file systems maybe be added in the future
ext2fs Linux EXT2 file system
Various file system independent parameters and contraints can be
specified, such as:
- minimum file system size (in KB)
- maximum file system size (in KB)
- free inodes
- free blocks (in KB)
- mtree(8) specification file containing permissions and ownership
to use in image, overridding the settings in the directory tree
- file containing list of files to specifically exclude or include
- fnmatch(3) pattern of filenames to exclude or include
- endianness of target file system
File system specific parameters can be given as well, with a command
line option such as "-o fsspeccific-options,comma-separated".
For example, ffs would allow tuning of:
- block & fragment size
- cylinder groups
- number of blocks per inode
- minimum free space
Other file systems might have controls on how to "munge" file names to
fit within the constraints of the target file system.
Exit codes:
0 all ok
1 fatal error
2 some files couldn't be added during image creation
(bad perms, missing file, etc). image will continue
to be made
Implementation overview:
------------------------
The implementation must allow for easy addition of extra file systems
with minimal changes to the file system independent sections.
The main program will:
- parse the options, including calling fs-specific routines to
validate fs-specific options
- walk the tree, building up a data structure which represents
the tree to stuff into the image. The structure will
probably be a similar tree to what mtree(8) uses internally;
a linked list of entries per directory with a child pointer
to children of directories. ".." won't be stored in the list;
the fs-specific tree walker should add this if required by the fs.
this builder have the smarts to handle hard links correctly.
- (optionally) Change the permissions in the tree according to
the mtree(8) specfile
- Call an fs-specific routine to build the image based on the
data structures.
Each fs-specific module should have the following external interfaces:
prepare_options optional file system specific defaults that need to be
setup before parsing fs-specific options.
parse_options parse the string for fs-specific options, feeding
errors back to the user as appropriate
cleanup_options optional file system specific data that need to be
cleaned up when done with this filesystem.
make_fs take the data structures representing the
directory tree and fs parameters,
validate that the parameters are valid
(e.g, the requested image will be large enough),
create the image, and
populate the image
prepare_options and cleanup_options are optional and can be NULL.
NOTE: All file system specific options are referenced via the fs_specific
pointer from the fsinfo_t strucutre. It is up to the filesystem to allocate
and free any data needed for this via the prepare and cleanup callbacks.
Each fs-specific module will need to add its routines to the dispatch array
in makefs.c and add prototypes for these to makefs.h
All other implementation details should not need to change any of the
generic code.
ffs implementation
------------------
In the ffs case, we can leverage off sbin/newfs/mkfs.c to actually build
the image. When building and populating the image, the implementation
can be greatly simplified if some assumptions are made:
- the total required size (in blocks and inodes) is determined
as part of the validation phase
- a "file" (including a directory) has a known size, so
support for growing a file is not necessary
Two underlying primitives are provided:
make_inode create an inode, returning the inode number
write_file write file (from memory if DIR, file descriptor
if FILE or SYMLINK), referencing given inode.
it is smart enough to know if a short symlink
can be stuffed into the inode, etc.
When creating a directory, the directory entries in the previously
built tree data structure is scanned and built in memory so it can
be written entirely as a single write_file() operation.