As of r126744, we no longer feed the entropy device in jails upon
start, and collecting them is no longer useful.
PR: conf/126744
Submitted by: Eugene Grosbein <eugen grosbein net> (with minor changes)
MFC after: 1 week
Approved by: so (des)
get them flagged as .NOPATH. This hurts people who don't use obj dirs.
Since its clean target seprate rm's for things, use NOPATH_FILES as list
to collect things that need .NOPATH.
bsd.obj.mk will add CLEANFILES to NOPATH_FILES and do the deed if needed.
Reviewed by: sbruno
+ Revert r2319 from serf 1.3.5: this change was making serf call handle_response
+ multiple times in case of an error response, leading to unexpected behavior.
+ Revert r2319 from serf 1.3.5: this change was making serf call handle_response
+ multiple times in case of an error response, leading to unexpected behavior.
enabled (which they are in the default configuration). Otherwise, it
will fail because ${XDDESTDIR}/usr/include/atf-c does not exist.
MFC after: 3 days
This change is a bit ugly, but so is the coupling between the i915
driver and syscons. It isn't worth developing a more elegant solution
only to support the legacy syscons console.
The hcreate(3) implementation and related functions we inherited
from NetBSD used to free() the key value, something that is not
supported by the standard implementation.
This would cause a segmentation fault when attempting to run
the examples from the opengroup and linux manpages. NetBSD
has added non-standard calls to provide the previous
behaviour but hdestroy is not very commonly used so at this
time it seems excessive to bring those to FreeBSD.
Bump the __FreeBSD_version as this is an ABI change.
Reference:
http://bugs.dragonflybsd.org/issues/1398
MFC after: 2 weeks
While testing this I found a conformance issue in hdestroy()
that will be fixed in a subsequent commit.
Obtained from: NetBSD (hcreate.c, CVS Rev. 1.7)
Use EBADF instead of EINVAL when working around incorrect O_ACCMODE.
Phabric: D442
Obtained from: Apple Inc. (Libc 997.90.3)
Reviewed by: jilles
MFC after: 1 week
columns available anyway. Also left align as we tend to do for flags
fields, although you can't see that currently as the string fully fills
that available columns.
MFC after: 3 days
Sponsored by: DARPA, AFRL
This has small changes to what Apple uses for compliance
with SUSv3. The changes cause no secondary effects in the
gnulib tests (we pass them).
Obtained from: Apple Inc. (Libc 997.90.3 with changes)
Reviewed by: bde
Phabric: D440
If RSS is enabled, ixgbe(4) will query the RSS API for the types of hashes
which should be used. It'll then only enable hashes that are exposed via
the RSS layer.
This way it won't try to do things like enable UDP hashing if RSS explicitly
states that it isn't supported in lookups.
Tested:
* 82599EB ixgbe(4) NIC
A mix of fragmented and non-fragmented UDP in a single stream will end up
being hashed differently, resulting in out-of-order behaviour in the receive
path.
This was done in the linux e1000 driver in 2011.
Discussed with: jfv
by the stack.
Right now the stack isn't really setup for RSS with 4-tuple UDP hashing
for either IPv4 and IPv6.
The specifics:
* The UDP init path udp_init() and udplite_init() specify the hash as
2-tuple, so the PCBGROUPS code only tries a 2-tuple check;
* The PCBGROUPS and RSS code doesn't know about the UDP hash types
just yet, so they're never treated as valid hashes.
* For correctness, 4-tuple can't be enabled in the general case because
UDP datagrams can be more fragmented than IP datagrams may be.
Strictly speaking, TCP datagrams may also be fragmented and this could
cause issues with PCBGROUPS/RSS until the IP defragment path grows some
code to re-calculate the RSS hash.
I'll follow this commit up with awareness of the UDP 4-tuple for those
who wish to configure it, but for now it'll stay disabled.
No drivers (yet) know to use this function when RSS is enabled.
handling. For statically linked apps this uses the __exidx_start/end
symbols set up by the linker. For dynamically linked apps it finds the
shared object that contains the given address and returns the location and
size of the exidx section in that shared object.
The dl_unwind_find_exidx() name is used by other BSD projects and Android,
and is mentioned in clang 3.5 comments as "the BSD interface" for finding
exidx data. GCC (in libgcc_s) expects the exact same API and functionality
to be provided by a function named __gnu_Unwind_Find_exidx(), so we provide
that with an alias ("strong reference").
Reviewed by: kib@
MFC after: 1 week
