dhcpcd-10 will be released in the next few week or so. Following that, I intend to update this diff to target importing dhcpcd into base ahead of the FreeBSD-14 code slush.

My testing seems to show this is working correctly
I've tested this by building a new FreeBSD-CURRENT disc1.iso, installing it into a bhyve VM that was booted with UEFI and installing with the default ZFS installer.
Upon reboot, the /boot/efi folder is automatically mounted by default with the FAT16 file system from /dev/gpt/efiboot0.
If I create files in the root directory with upper case names, the output of "df -i" increases by 1. If I use lower case names, it increases by 2. If I use long names, it increases by bigger increments depending on the length of the name.
Once I create enough files that I am no longer able to create more files in the root directory (error is "No space left on device"), then "df -i" shows the inodes are 100% full.

In D38987#887609, @mckusick wrote:

How difficult would it be to make it also work for FAT32 filesystems?

Hi Stefan,

Sorry for not providing an update on this sooner.
The summary is I was waiting on the next release of dhcpcd before proceeding with importing it into base.
The reason was a regression related to capsicum was noticed with FreeBSD-14 starting in August 2022 where the privilged process could no longer write to the routing table. This issue isn't occurring on FreeBSD-13, nor FreeBSD-14 from 2021.
@roy_marples.name found and fixed the issue in dhcpcd, but only in what will become dhcpcd-10 (it's too invasive for dhcpcd-9 at this point which is the stable branch).
The dhcpcd-10 has been delayed a bit, since Roy has a few health issues that are his priority right now.
That said, I'm still hoping this can be merged into FreeBSD-14 before the code slush begins on 25th April 2023.

Added the FREEIPMI plist entry back in

I have compared my patch with that provided by Namkhai B. <me@forkbomb9.ch> - they are almost identical (great minds think alike).
A few minor differences outlined below - I'll update the review with the FREEIPMI plist entry added back in. No other changes necessary.

It wasn't really clear to me what is changed in the custom dashboard which was previously applied when the CLOUD option was disabled during the FreeBSD port build.

ping @nc - any thoughts on this proposed change to the default options of the net-mgmt/netdata port?

In D37453#851587, @diizzy wrote:

This should be a flavor rather than default?

Interesting - I hadn’t noticed any issue during my previous testing - thanks for finding and fixing this

Thanks - you happy for me to put approved by: philip (your src commit approval)?

Looks good to me. Thanks for all your work on making the bridge interface faster and more user friendly Kristof!

Looks good! Can I propose also adding some additional info describing the new behaviour when the MTU of an existing bridge is changed?

In D36222#826605, @manu wrote:

In D36222#826524, @woodsb02 wrote:

In D36222#826487, @imp wrote:

How else would you package rescue? It's a single binary with lots of hard links. It makes no sense to
package it as anything other than a single package.

I’m thinking of the situation where I’ve decided I don’t want dhclient, so I remove the dhclient package (or never install it) but I do have the rescue package.

As long as we build dhclient by default (we don't have WITH_DHCLIENT or something like that right now) dhclient will always be part of rescue.

In that case would the /rescue/dhclient be a hard link to nowhere, or would it contain its own copy of the file?

All rescue binaries are crunched together with crunchgen in /rescue/rescue and then we create some hardlink for all the files that we crunched so without installing FreeBSD-dhclient you will still have a dhclient in /rescue.

In D22012#826644, @pauamma wrote:

Some or all of this needs pushing upstream instead of/in addition to local changes. Since the upstream maintainer is subscribed, I haven't made the distinction.

In D22012#826694, @imp wrote:

In D22012#826671, @roy_marples.name wrote:

In D22012#826669, @emaste wrote:

I'd suggest updating this review to be a diff against the copy of dhcpcd now in vendor/ merged into contrib/, so that changes if any to existing dhcpcd files are clear

That would help me greatly bringing any changes requested here upstream.

and hopefully it will be easier to review here too :)
Win win

In D22012#826669, @emaste wrote:

I'd suggest updating this review to be a diff against the copy of dhcpcd now in vendor/ merged into contrib/, so that changes if any to existing dhcpcd files are clear

In D22012#826551, @moonlapse81_gmail.com wrote:

how to specifically disable ipv6 ( or ipv4 ) when dhcpcd is in /usr/src?

Fix build WITHOUT_INET=yes: move SRCS+=privsep-bpf.c inside .if ${MK_INET_SUPPORT}

In D36222#826487, @imp wrote:

How else would you package rescue? It's a single binary with lots of hard links. It makes no sense to
package it as anything other than a single package.

Fix build Makefile by adding .include <src.opts.mk>

Close comments which have been implemented

Implement review comments:

• Add dhcpcd as a separate package (not in "runtime" package)
• Allow dhcpcd to be compiled without IPv4 or IPv6 support
• Remove duplicate system directory configuration
• Bump manpage dates
• Simplify rc.conf(5) language describing master mode

This makes we wonder if the contents of /rescue should remain as a single rescue package... or if its contents should include files from other packages (like this dhclient package)?

A new vendor/dhcpcd branch has now been created in the src repo.
https://cgit.freebsd.org/src/commit/?h=vendor/dhcpcd&id=96dba636abec6d5451820add99300bda2ca6d86a

Committed.
https://cgit.freebsd.org/src/commit/?h=vendor/dhcpcd&id=96dba636abec6d5451820add99300bda2ca6d86a

Looks good 👍

You’re probably already aware, but ports has a commit hook so that commit messages should start the first line with “category/portname: description”.

All the proposed changes look fine to me. You’re welcome to commit this to ports yourself with my ports commit bit approval.

Remove any changes to rc scripts other than adding the new
/etc/rc.d/dhcpcd

I posted on the freebsd-net mailing list to raise the proposal once again with the broader community

In D22012#818455, @emaste wrote:

As far as I can tell the objections that were raised over the last few years have all been addressed, and it doesn't seem like much progress has been made on the proposed alternatives. It seems reasonable to me to import dhcpcd initially controlled by a build knob (i.e., WITH_DHCPCD) to allow for further development and experimentation.

In D22012#818780, @gbe wrote:

Just one note, OpenBSD has recently implemented a new DHCP client called dhcpleased, which has a very small code size and should be checked before we integrated this patch.

Text in the if_bridge(4) manpage to consider updating:

Not sure why this review wasn’t automatically closed by the commit.

Thanks for preparing this change!

Fix a few missing compile items with the new version 9.4.1

Fix patch to be against head, not against the previous version of the review

Update dhcpcd(8) to version 9.4.1

Rebase D22012 against FreeBSD src HEAD 362c6d8

This was only ever a test to see the arc raw diff format for new files.
For some reason, "arc patch --patch <file>" fails to apply patches downloaded as raw diffs from reviews.freebsd.org

Add a line

phabricator blunder - never meant to create a review for this existing commit!?

I think the vt(4) manpage should be updated to show this change in defaults? Could also be worth a note in UPDATING?

Given 11.4 EOL is 30th September, is the plan to remove support for 11.4 from ports before the 2021Q4 quarterly is branched?

Thanks @ericbsd.
@madpilot are you able to provide your thoughts on behalf of desktop@?