@glebius : I appreciate what you're trying to solve, but @kib brings up a very good point.
My concern with the change is that code (especially third-party/ports code) may naïvely assume a lock type is X, when in fact it's Y after the change. Anti-patterns like this seem ripe for improper memory accesses/potential scribblers..

Approved by: ngie (co-mentor)

Approved by: ngie (co-mentor)

In D59227#1362854, @nickbanks_netflix.com wrote:

In D59227#1362798, @ngie wrote:

Please doublecheck that the new support also meets your needs before committing.

I confirmed that all our internal tests here at Netflix were passing still with the updated commit.

In D59411#1362818, @kevans wrote:

No idea why I would have done this, I've done plenty of atf-c... thanks!

Please doublecheck that the new support also meets your needs before committing.

In D42156#1362778, @ngie wrote:

How about approaching this slightly differently? If ${PORTSDIR} is not defined in the environment, use /usr/ports. e.g., PORTSDIR?= /usr/ports (using make syntax). That drops the need for adding a for-loop to handle both cases and touching/reformatting a ton of code.

If the user passes a non-existent ${PORTSDIR} -- that's their mistake; don't contort too much trying to check for both scenarios (I assume that the number of folks that specify a ${PORTSDIR} != /usr/ports is likely small and they should know what they're doing if they specify the override).

How about approaching this slightly differently: if ${PORTSDIR} is not defined in the environment, use /usr/ports. e.g., PORTSDIR?= /usr/ports (using make syntax). That drops the need for adding a for-loop to handle both cases and reformatting a ton of code.

A fix was submitted for this already: https://reviews.freebsd.org/D59346 .

@igoro when the time comes, could you please submit this upstream as well along with the prepare support?

Approved by: ngie (co-mentor)

Approved by: ngie (co-mentor)

Approved by: ngie (co-mentor)

Please use require.kmods instead of the macro as I recommend in the differential.

Just whitespace nitpicks.

This didn't apply cleanly on :main for me -- I think it needs to be rebased.

Approved by: ngie (co-mentor)

I think the prior approach suggested by @dim to make as minimal of a change as possible makes a lot of sense: there's no real single-maintainer in inetd and the daemon has remained in maintenance mode for many years.

@alfred was the one who touched the line last, but he's been inactive for many years now.
@des or @kevans: this change seems straightforward, but do you have any objections to this change? I ask because Klara has taken an active role at cleaning up portions of the base system lately.