right place. Reported by Jonathan Chen <jonc@pinnacle.co.nz> (someone with
the same name who's not me)
PR: i386/8414
Submitted by: Jonathan Chen <jonc@pinnacle.co.nz>
MFC after: 2 weeks
be malloc()ed, but they are now allocated using mmap(), just as the
default-size stacks are. A separate cache of stacks is kept for
non-default-size stacks.
Collaboration with: deischen
- Lose any stray host bits that a user may have entered when providing
a network number and netmask to the `-a' option for IPv6. This is
corresponding to 1.79 that is for IPv4 only.
MFC after: 1 week
- Don't assume environment variable HOME is not NULL.
o Integrate standards compliance from NetBSD.
- Allow -- before the command.
- Blocking SIGQUIT isn't standards compliant.
- Proper exit(3) levels.
- Actually append to nohup.out (as documented and required
by standard) instead of clobbering it.
o Remove some FreeBSD specific access(2) cruft (relating to
incorrect appending).
o Document the fact that two or more instances of nohup can
append to the same file.
o Constify; Staticize functions; Set WARNS?=2
Reviewed by: bde
Approved by: des
Obtained from: NetBSD, OpenBSD
MFC after: 9 days
to give up after one attempt unless a background mount is requested.
Background mounts would retry 10000 times (at least 7 days) before
giving up.
For some situations such as diskless terminals, an NFS filesystem
may be critical to the boot process, so neither the "try once" nor
background mounts are appropiate. To cater for this situation,
unbreak the -R (retry count) parameter so that it also works in
the non-background case. Interpret a zero retry count as "retry
forever".
The defaults are now "try once" for non-background mounts and "retry
forever" for background mounts; both can be overridden via -R.
Add a description of this behaviour to the manpage.
the SYNOPSIS hasn't had an example number of devices since rev 1.2 which
was over 5 and a half years ago, so remove a sentence claiming that the
example in the SYNOPSIS limited bpf to 16 devices.
MFC after: 3 days
in the background. fsck_ffs uses `5' for when SOFTUPDATES are not set,
and thus background cleaning cannot take place. That seems to [semi-]apply
here. So I don't know what non-zero value to use.
If anyone has an opinion, let me know.
it may be plugged into a kernel that supports VLANs. If the kernel is
not VLAN aware, things will still work as before.
Modules don't really have option support, so this is somewhat of a hack.
