the monitored directory as the result of rename(2) operation. The
renames staying in the directory are not reported.
Submitted by: Vladimir Kondratyev <wulf@cicgroup.ru>
MFC after: 2 weeks
rename removing or adding subdirectory entry.
Discussed with and tested by: Vladimir Kondratyev <wulf@cicgroup.ru>
NetBSD PR: 48958 (http://gnats.netbsd.org/48958)
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
* break out the operating mode and rx filter into new functions, rather
than them being hard-coded
* if we're in sniffer mode or not associated, set the BSS MAC to all zero,
rather than relying on a chip reset to do it for us
* add comments about .. how interestingly buggy the chip is.
Tested:
* AR9170 + AR9102, STA+monitor mode
Obtained from: linux carl9170 (general chip workings, constant definitions)
Switch to add_channel / add_channel_ht40 + pass channel's TX power
for the last.
Tested by: dhw
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D6141
chunk, enable UDP encapsulation for all those addresses.
This helps clients using a userland stack to support multihoming if
they are not behind a NAT.
MFC after: 1 week
This is based on a change from OpenBSD:
"Fix restore so that it can actually restore files larger than 4GB by
changing the type of "size" to off_t in getfiles() plus little dependent
type cleanup, from Daniel Lucq."
It is an important for machines with 32 bit longs.
While here unsign the flags, also from OpenBSD.
Obtained from: OpenBSD (through bitrig, I hate CVS)
MFC after: 2 weeks
The new bcache code does not know the size of the disk, and therefore may attempt to read past the end of the disk while trying to fill its read-ahead cache.
This is usually not an issue, it fails gracefully on all of my machines, but some BIOSes seem to retry the reads for up to 30 seconds each, resulting in a long stall during boot
Submitted by: Toomas Soome <tsoome@me.com>
Reviewed by: jhb, np
Differential Revision: https://reviews.freebsd.org/D6109
a basic usage example. Although it is an
untypical example for the use of kqueue, it is
better than nothing and should get people started.
PR: 196844
Submitted by: fernando.apesteguia@gmail.com
Reviewed by: kib
Approved by: kib
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D6082
Avoid logging inconsistency for the /dev/mem device at all. The driver
leaves memattr intact, and the corrective action in the device pager
handles it right.
In the logged warning, name the driver we blame, and show memory
attributes values.
Reported and tested by: pho
Reviewed by: alc
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D6149
driver is (or behaves identically to) /dev/mem. Remove the D_MEM flag
from random drivers.
Note that currently the D_MEM flag does not affect any behaviour, but
this going to change in the next commit.
Noted and reviewed by: alc
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
X-Differential revision: https://reviews.freebsd.org/D6149
There are a couple of places in the source three where we call
basename() on constant strings. This is bad, because the prototype
standardized by POSIX allows the implementation to use its argument as a
storage buffer.
This change eliminates some of these unportable calls to basename() in
cases where it was only added for cosmetical reasons, namely to trim
argv[0]. There's nothing wrong with setting argv[0] to the full path.
Reviewed by: jilles
Differential Revision: https://reviews.freebsd.org/D6093
The Linux driver sets the rate_n_flags regardless of whether it's being
sent using firmware rate control or local rate control. This includes
the antenna configuration.
Thanks to Kyle Evans <kevans91@ksu.edu> for pointing this out to me
and doing some investigation/testing on his end.
Tested:
* Intel 7260 STA, 2G and 5G networks
