update the documentation to reflect that.
PR: docs/86090
Submitted by: Lowell Gilbert <freebsd-bugs-local at be-well dot ilk point org>
MFC after: 3 days
MFC to: RELENG_5, RELENG_6
from accept(2) and fork(2). Also close all unneeded fds
in the child process, namely listening sockets for all
address families and the fd initially obtained from accept(2).
(The main ftpd code operates on stdin/stdout anyway as it
has been designed for running from inetd.)
MFC after: 5 days
By default, create a pid file at the standard location, /var/run/ftpd.pid,
in accord with the expected behavior of a stock system daemon.
MFC after: 5 days
Vararg functions have a different calling convention than regular
functions on amd64. Casting a varag function to a regular one to
match the function pointer declaration will hide the varargs from
the caller and we will end up with an incorrectly setup stack.
Entirely remove the varargs from these functions and change the
functions to match the declaration of the function pointers.
Remove the now unnecessary casts.
Lots of explanations and help from: peter
Reviewed by: peter
PR: amd64/89261
MFC after: 6 days
o fix contention window
o silently discard received frames that are too short
o simplify lookup of 802.11a channels (we know they exist)
o fix short preamble support
o add short slot support
o fix eifs settings
o many consistency tweaks
share devclass pointers, a mistake I've encouraged in the past) and
move the declaration of the pci_driver kobj class from cardbus.c to
pci_private.h so that other drivers can inherit from pci_driver.
devclass's parent pointer if the two drivers share the same devclass. This
can happen if the drivers use the same new-bus name. For example, we
currently have 3 drivers that use the name "pci": the generic PCI bus
driver, the ACPI PCI bus driver, and the OpenFirmware PCI bus driver. If
the ACPI PCI bus driver was defined as a subclass of the generic PCI bus
driver, then without this check the "pci" devclass would point to itself
as its parent and device_probe_child() would spin forever when it
encountered the first PCI device that did have a matching driver.
Reviewed by: dfr, imp, new-bus@
went away in the generated files? This didn't happen on my amd64
test machine but did when I committed it on my other i386 machine.
I need to figure this out since a regen on the amd64 doesn't fix it
now. For now make the build work again. Matt caught this before
my local mirror caught up.
This fixes reconnect after, for example, tcp idle disconnection.
Previously this would fail if a normal user tried to bind to a privileged
port.
Submitted by: cel@citi.umich.edu
MFC after: 1 week
hacking:
- Remove all spaces at eol.
- Improve style(9) in most frequently edited functions.
- In em_encap() push variables for 82544 workaround in the block
where they are only used.
- In em_get_buf() remove unused variable.
errors from rn_inithead back to the ipfw initialization function.
- Check return value of rn_inithead for failure, if table allocation has
failed for any reason, free up any tables we have created and return ENOMEM
- In ipfw_init check the return value of init_tables and free up any mutexes or
UMA zones which may have been created.
- Assert that the supplied table is not NULL before attempting to dereference.
This fixes panics which were a result of invalid memory accesses due to failed
table allocation. This is an issue mainly because the R_Zalloc function is a
malloc(M_NOWAIT) wrapper, thus making it possible for allocations to fail.
Found by: Coverity Prevent (tm)
Coverity ID: CID79
MFC after: 1 week
they have been rotated. Among other things, use warnx() instead of warn()
for some messages where the value if errno is irrelevant to the problem
being reported.
MFC after: 5 days
problems in cases where regions are faked up for the purposes of red-black
tree searches, since those faked region headers reside on the stack, rather
than in a malloc chunk.
