purpose, other than to get in the way of the ARP table and cause
"can't allocate llinfo" errors.
This change may cause gated or routed to start complaining when adding
such routes. If so, these programs will need to be fixed to not try
to add these routes.
Reviewed by: wollman
(suggested by Darryl Okahata).
* Add explanation of what virtual consoles are
(suggested by Francisco Reyes)
* Minor formatting change to fix docs/1378 (could some kind person
close this for me? Thanks!)
* Removed references to obsolete /usr/share/FAQ/Text directory.
* Added details of UK supplier of FreeBSD CDs.
* Made the consequences of running ``make world'' more explicit.
* More cleaning and tidying up.
- State when we've reached the limit on a particular rule in the kernel logfile
- State when a rule or all rules have been zero'd.
This gives a log of all actions that occur w/regard to the firewall
occurances, and can explain why a particular break-in attempt might not
get logged due to the limit being reached.
Reviewed by: alex
the high kernel calls into a protocol stack to perform requests on the
user's behalf. We replace the pr_usrreq() entry in struct protosw with a
pointer to a structure containing pointers to functions which implement
the various reuqests; each function is declared with the correct type and
number of arguments. (This is unlike the current scheme in which a quarter
of the requests take arguments of type other than (struct mbuf *) and the
difference is papered over with casts.) There are a few benefits to this
new scheme:
1) Arguments are passed with their correct types, and null-pointer dummies
are no longer necessary.
2) There should be slightly better caching effects from eliminating
the prximity to extraneous code and th switch in pr_usrreq().
3) It becomes much easier to change the types of the arguments to something
other than `struct mbuf *' (e.g.,pushing the work of sosend() into
the protocol as advocated by Van Jacobson).
There is one principal drawback: existing protocol stacks need to
be modified. This is alleviated by compatibility code in
uipc_socket2.c and uipc_domain.c which emulates the new interface
in terms of the old and vice versa.
This idea is not original to me. I read about what Jacobson did
in one of his papers and have tried to implement the first steps
towards something like that here. Much work remains to be done.
option for installing distributions and/or packages to somewhere other than /,
say for a case where you're installing to an external disk on some other
machine's behalf. More miscellaneous fixes to various problems I stumbled
across while adding this stuff.
comprehensive re-write later.
* Ruthlessly condense questions so they fit on a single line (the
TOC is now actually readable in lynx!). In one or two cases, this
has meant splitting up questions or incorporating part of the old
question into the answer.
* Make it clear that the question about disklabel'ing is actually
about adding a second hard disk, provide a _much_ simpler answer and
move it out of the installation section.
* Don't imply that the AHA2920 is supported (I suspect we will get a
lot of queries about this)
* Reword the non-serious questions to hint that the answer may not be
particularly informative...
* Correct typos and grammar, remove US-centric colloquialisms :-)
and many more.
control program to control the facility of the bootblocks
to fetch a default bootstring from a fixed location on the disk.
See the manpage for more info.
type identification code out of machdep.c and into a new file of its
own. Hopefully other grot can be moved out of machdep.c as well
(by other people) into more descriptively-named files.
performance to LRU or worse when RSS limiting takes effect. Also,
make an end condition in the active queue scan more efficient in the
case where pages are removed from the active queue as a side effect
of a pmap operation.
it with the CIRCLEQ macros. This simplifies the code a little, makes
it somewhat easier to read, and may be a little faster. (Actually I think
the performace is about the same.)
Also, in the non DB_CACHE case, save copies of data returned from
the database library in a static buffer, just in case we decide to use
it after the database has been closed. Technically, the memory that the
data pointers refer to belongs to the DB package and we can't count on
it being there after the database has been closed -- the DB package
frees its buffers. (With DB_CACHE #defined the databases are held
open so the buffers remain valid.) I don't think any of the utilities
that use the dblookup module have had any problems with this yet, but
there's no sense in taking any chances.
