r361721 cy June 2, 2020, 3:44 a.m.
filter rule lists.

MFC after:	3 days
ViewVC
r361720 kevans June 2, 2020, 2:38 a.m.
When WITHOUT_SENDMAIL is set, we end up with two different mailer.conf that
conflict, and hilarity ensues. There's currently three different places that
we might install mailer.conf:

- ^/etc/Makefile (package=runtime, contingent on MK_MAIL != no)
- ^/libexec/dma/dmagent/Makefile (package=dma, contingent on MK_SENDMAIL !=
no)
- ^/usr.sbin/mailwrapper/Makefile (package=utilities, contingent on
not-installed)

The mailwrapper installation will effectively never happen because the ^/etc
one will first.

This patch simplifies the whole situation; remove the ^/etc/Makefile version
and install it primarily in mailwrapper if MK_MAILWRAPPER != "no". The
scenarios covered in mailwrapper are:

- sendmail(8) is installed, dma(8) may or may not be installed
- neither sendmail(8) nor dma(8) is installed

In the first scenario, sendmail(8) is dominant so we can go ahead and
install the version in ^/etc/mail. In the unlisted scenario, sendmail(8) is
not installed but dma(8) is, we'll let ^/libexec/dma/dmagent do the
installation. In the second listed scenario, we still want to install an
example mailer.conf so just install the base sendmail(8) version.

Reviewed by:	bapt
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D24924
ViewVC
r361719 jah June 2, 2020, 1:21 a.m.
r361601 implemented basic support for cleaing the console history buffer.
But after clearing the history buffer, it's not especially useful to be
able to scroll back through that buffer, or for the cursor position to
remain at (very likely) the bottom of the screen.

PR:		224436
Reviewed by:	emaste
Differential Revision:	https://reviews.freebsd.org/D25079
ViewVC
r361718 wulf June 2, 2020, 1:04 a.m.
which happens on some laptops after returning to legacy multiplexing mode
at initialization stage.

PR:		242542
Reported by:	Felix Palmen <felix@palmen-it.de>
MFC after:	1 week
ViewVC
r361715 wulf June 2, 2020, 12:53 a.m.
PR:		246117
Reported by:	Alexander Sieg <ports@xanderio.de>
MFC after:	1 week
ViewVC
r361713 emaste June 2, 2020, 12:46 a.m.
And a comment explaining why PIE flags are disabled for static binaries.
ViewVC
r361712 kevans June 2, 2020, 12:32 a.m.
IPSEC_SUPPORT can currently only cope with either IPSEC || IPSEC_SUPPORT,
not both. Refrain from building if IPSEC is set, as the resulting module
won't be able to load anyways if it's built into the kernel.

KERN_OPTS is safe here; for tied modules, it will reflect the kernel
configuration. For untied modules, it will defer to whatever is set in
^/sys/conf/config.mk, which doesn't set IPSEC for modules. The latter
situation has some risk to it for uncommon scenarios, but such is the life
of untied kernel modules.

Reported by:	jenkins (a lot), O. Hartmann (once)
Generally discussed with:	imp, jhb
ViewVC
r361711 rmacklem June 2, 2020, 12:03 a.m.
Reported by:	cy (and others)
ViewVC
r361710 sjg June 1, 2020, 11:44 p.m.
Missplaced paren.

Reviewed by:	imp
MFC after:	1 week
ViewVC
r361709 kevans June 1, 2020, 11:26 p.m.
At least one user has landed in a scenario where logo files appear to be
misnamed, and we failed to find them. Our fallback for missing logodefs is
orb/orbbw, based on the color status. In a scenario where we can't locate
the logos, though, this is not ideal. Add in one more layer of fallback
to properly just don't draw any logo if the fan has been jam packed with
foreign material.

PR:		246046
MFC after:	3 days
ViewVC
r361708 melifaro June 1, 2020, 9:52 p.m.
Currently there is no easy way of subscribing for the routing table changes.
The only existing way is to set ifa_rtrequest callback in the each protocol
 ifaddr, which is not convenient or extandable.

This change provides generic notification subscription mechanism, that will
 replace current ifa_rtrequest one and allow other applications such as
 accelerated routing lookup modules subscribe for the changes.

In particular, this change provides 2 hooks: 1) synchronous one
 (RIB_NOTIFY_IMMEDIATE), called under RIB_WLOCK, which ensures exact
 ordering of the changes and 2) async one, (RIB_NOTIFY_DELAYED)
 that is called after the change w/o holding locks. The latter one does not
 provide any notification ordering guarantee.

Differential Revision:  https://reviews.freebsd.org/D25070
ViewVC
r361707 melifaro June 1, 2020, 9:51 p.m.
r361706 melifaro June 1, 2020, 8:49 p.m.
The main driver for the change is the need to improve notification mechanism.
Currently callers guess the operation data based on the rtentry structure
 returned in case of successful operation result. There are two problems with
 this appoach. First is that it doesn't provide enough information for the
 upcoming multipath changes, where rtentry refers to a new nexthop group,
 and there is no way of guessing which paths were added during the change.
 Second is that some rtentry fields can change during notification and
 protecting from it by requiring customers to unlock rtentry is not desired.

Additionally, as the consumers such as rtsock do know which operation they
 request in advance, making explicit add/change/del versions of the functions
 makes sense, especially given the functions don't share a lot of code.

With that in mind, introduce rib_cmd_info notification structure and
 rib_<add|del|change>_route() functions, with mandatory rib_cmd_info pointer.
 It will be used in upcoming generalized notifications.

* Move definitions of the new functions and some other functions/structures
 used for the routing table manipulation to a separate header file,
 net/route/route_ctl.h. net/route.h is a frequently used file included in
 ~140 places in kernel, and 90% of the users don't need these definitions.

Reviewed by:		ae
Differential Revision:	https://reviews.freebsd.org/D25067
ViewVC
r361705 melifaro June 1, 2020, 8:40 p.m.
r361704 melifaro June 1, 2020, 8:32 p.m.
The main driver for the change is the need to improve notification mechanism.
Currently callers guess the operation data based on the rtentry structure
 returned in case of successful operation result. There are two problems with
 this appoach. First is that it doesn't provide enough information for the
 upcoming multipath changes, where rtentry refers to a new nexthop group,
 and there is no way of guessing which paths were added during the change.
 Second is that some rtentry fields can change during notification and
 protecting from it by requiring customers to unlock rtentry is not desired.

Additionally, as the consumers such as rtsock do know which operation they
 request in advance, making explicit add/change/del versions of the functions
 makes sense, especially given the functions don't share a lot of code.

With that in mind, introduce rib_cmd_info notification structure and
 rib_<add|del|change>_route() functions, with mandatory rib_cmd_info pointer.
 It will be used in upcoming generalized notifications.

* Move definitions of the new functions and some other functions/structures
 used for the routing table manipulation to a separate header file,
 net/route/route_ctl.h. net/route.h is a frequently used file included in
 ~140 places in kernel, and 90% of the users don't need these definitions.

Reviewed by:	ae
Differential Revision: https://reviews.freebsd.org/D25067
ViewVC