very specific scenarios, and now that we have had net.inet.tcp.blackhole for
quite some time there is really no reason to use it any more.
(last of three commits)
very specific scenarios, and now that we have had net.inet.tcp.blackhole for
quite some time there is really no reason to use it any more.
(second of three commits)
very specific scenarios, and now that we have had net.inet.tcp.blackhole for
quite some time there is really no reason to use it any more.
(first of three commits)
to run PPP over Radiocontact T-Link Radio Modems which run best when something
is transmitted at least every 1.5 seconds.
Tested by: Jennifer Clark <jen@telepresence.strath.ac.uk>
Approved by: Brian
number of paths which glob(3) will return. Remove the hardcoded limit
from the last commit, which restores the previous unbounded behavior.
Document the new flag in the manual page.
associated changes that had to happen to make this possible as well as
bugs fixed along the way.
Bring in required TLI library routines to support this.
Since we don't support TLI we've essentially copied what NetBSD
has done, adding a thin layer to emulate direct the TLI calls
into BSD socket calls.
This is mostly from Sun's tirpc release that was made in 1994,
however some fixes were backported from the 1999 release (supposedly
only made available after this porting effort was underway).
The submitter has agreed to continue on and bring us up to the
1999 release.
Several key features are introduced with this update:
Client calls are thread safe. (1999 code has server side thread
safe)
Updated, a more modern interface.
Many userland updates were done to bring the code up to par with
the recent RPC API.
There is an update to the pthreads library, a function
pthread_main_np() was added to emulate a function of Sun's threads
library.
While we're at it, bring in NetBSD's lockd, it's been far too
long of a wait.
New rpcbind(8) replaces portmap(8) (supporting communication over
an authenticated Unix-domain socket, and by default only allowing
set and unset requests over that channel). It's much more secure
than the old portmapper.
Umount(8), mountd(8), mount_nfs(8), nfsd(8) have also been upgraded
to support TI-RPC and to support IPV6.
Umount(8) is also fixed to unmount pathnames longer than 80 chars,
which are currently truncated by the Kernel statfs structure.
Submitted by: Martin Blapp <mb@imp.ch>
Manpage review: ru
Secure RPC implemented by: wpaul
- lowercase Nd argument
- mark function arguments with Fa
- mark defined values with Dv
- simply copying POSIX text for RETURN VALUES and ERRORS sections is not
always a good idea. POSIX uses the word "shall" indicating the behavior
the correct implementation should follow.
o Attempt to disable the slot when we detect that there are problems with
it in our ISR. This should make polling mode work better for more cards,
but more work may be needed. This "disabling" sets the card interrupt
register to 0. This worked for me for lots of tests in polling mode.
o Now that I've found datasheets, fix a boatload of magic numbers in the
source to make it easier to understand.
o Use a table of names rather than a big case statement.
o Cull a few of the "unused" controller types that we map to other times
that were a vestiage of PAO code that we never merged in the same way.
o Enforce legal IRQs. You are no longer allowed to try to use IRQs that
will fail on all known ISA/PCI <-> PCMCIA bridges. The bridges do not
have pins for these illegal interrupts, and all of them are listed as
reserved and/or illegeal in the datasheets depending on which one you
look at.
o Add comments about how IBM-AT based computers and NEC PC-98 based computers
map these interrupts and which ones are valid.
o Always clear the bit that steers the management interrupt either to the
value listed in the PCIC_STAT_INT register. I've seen this bit get set
on suspend/resume and after windows boot, and it does't hurt to clear it.
NOTE: this might mean we can share this interrupt in the future.
is under-tested, and that MFS appears to be in the process of being
deprecated in favor of FFS over md. Note also that UFS_EXTATTR_AUTOSTART
doesn't make much sense on MFS unless the MFSROOT is compiled in, so
manual configuration is generally required.
Obtained from: TrustedBSD Project