Consensus seems to be that eliding blank lines for functions with no local
variables is acceptable. Codify that explicitly in the style document.
Reported by: jhb
Reviewed by: delphij, imp, vangyzen (earlier version); rgrimes
With feedback from: kib
Differential Revision: https://reviews.freebsd.org/D20448
ccr depends on symbols exported by the cxgbe driver as well as having
a runtime dependency. While the runtime depenency was noted in the
manpage already, the compile-time dependency wasn't as clear.
PR: 238265
MFC after: 3 days
Sponsored by: Chelsio Communications
Other frameworks, such as googletest, should be added there as well,
once they become viable. For now let's keep it simple.
Discussed with: ngie, emaste
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20124
struct xucred. Do not bump XUCRED_VERSION as struct layout is not changed.
PR: 215202
Reviewed by: tijl
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D20415
The issues were pointed in community review:
https://reviews.freebsd.org/D10427#inline-67587
Also, fix other issues found by the igor tool.
Submitted by: Michal Krawczyk <mk@semihalf.com>
Obtained from: Semihalf
Sponsored by: Amazon, Inc.
* F_RDLCK, F_UNLCK, and F_WRLCK aren't flags. They're stored in the
fl.l_type field.
* Add F_REMOTE, added in r177633
* Add F_NOINTR, added in r180025
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Due to how the linker.hints file is laid out, we'll associate the pnp
info with the wrong module if the module declaration comes after the
pnp info. Until that limiation is removed, we need to have this
ordering. Ideally, we'd also enforce the ordering somehow, but I've
come up with no way to do that yet...
Revison 222167 added a new argument to VFS_FHTOVP. This revision updates the
man page to match.
Reviewed by: rmacklem
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D20323
ed(4) and ep(4) have been removed. fxp(4) remains popular in older
systems, but isn't as future proof as em(4).
Reviewed by: bz, jhb
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D20311
This is described in the vmem paper: "directs vmem to use the next free
segment after the one previously allocated." The implementation adds a
new boundary tag type, M_CURSOR, which is linked into the segment list
and precedes the segment following the previous M_NEXTFIT allocation.
The cursor is used to locate the next free segment satisfying the
allocation constraints.
This implementation isn't O(1) since busy tags aren't coalesced, and we
may potentially scan the entire segment list during an M_NEXTFIT
allocation.
Reviewed by: alc
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D17226
tun(4) and tap(4) share the same general management interface and have a lot
in common. Bugs exist in tap(4) that have been fixed in tun(4), and
vice-versa. Let's reduce the maintenance requirements by merging them
together and using flags to differentiate between the three interface types
(tun, tap, vmnet).
This fixes a couple of tap(4)/vmnet(4) issues right out of the gate:
- tap devices may no longer be destroyed while they're open [0]
- VIMAGE issues already addressed in tun by kp
[0] emaste had removed an easy-panic-button in r240938 due to devdrn
blocking. A naive glance over this leads me to believe that this isn't quite
complete -- destroy_devl will only block while executing d_* functions, but
doesn't block the device from being destroyed while a process has it open.
The latter is the intent of the condvar in tun, so this is "fixed" (for
certain definitions of the word -- it wasn't really broken in tap, it just
wasn't quite ideal).
ifconfig(8) also grew the ability to map an interface name to a kld, so
that `ifconfig {tun,tap}0` can continue to autoload the correct module, and
`ifconfig vmnet0 create` will now autoload the correct module. This is a
low overhead addition.
(MFC commentary)
This may get MFC'd if many bugs in tun(4)/tap(4) are discovered after this,
and how critical they are. Changes after this are likely easily MFC'd
without taking this merge, but the merge will be easier.
I have no plans to do this MFC as of now.
Reviewed by: bcr (manpages), tuexen (testing, syzkaller/packetdrill)
Input also from: melifaro
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D20044
device_printf does multiple calls to printf allowing other console messages to
be inserted between the device name, and the rest of the message. This change
uses sbuf to compose to two into a single buffer, and prints it all at once.
It exposes an sbuf drain function (drain-to-printf) for common use.
Update documentation to match; some unit tests included.
Submitted by: jmg
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D16690
