Since the module will be built for all arch why not adding the config to sys/conf/files directly ? It's already present in files.amd64 and files.powerpc and now you're adding this to files.arm64, it doesn't make sense.

Maybe start with enabling the module for arm64 ?
It's unlikely that anyone will test adding the driver to their kernel config if they didn't tested with the module before.
Also I don't see why anyone would want the driver in the kernel if a module exists.

In D54253#1239650, @pkubaj wrote:

The real problem is mentioned here: https://wiki.freebsd.org/BjoernZeeb/Ten64

If loaded as module from multi-user we do not get the time set even if manually triggering a sysctl debug.clock_do_io=1. Reason for this is that vfs_moutroot() is responsible to have the clock set and calls CLOCK_GETTIME() indirectly so that log files or other timestamps do not appear to go backwards (if no RTC is found it'll use the vfs root node date?). Look for the inittodr() call.

That's clearly not the way to go, finding the real problem is what you need to do.

In D54193#1238097, @ivy wrote:

please include

Fixes: 436618a427b4 ("etc/mtree: Add package tags for /usr/include")

so we can undo these changes later once we have a better solution. otherwise, looks fine.

Not sure I like that but I could be ok if people wants this. Is this package vital ?

My rational for putting them into runtime is that if anything goes wrong and only runtime and clibs are upgraded you can boot to single user and debug network functionality.

I don't remember why I put it in -runtime back then

In D52494#1198878, @imp wrote:

So does this work with our arm64 boards that use a u-boot provied EFI image? The comment are for this case, though we really only care about the last u-boot or two, not ancient history.

I like it that way but if the majority of our users wants this I'll not complain :)

So they will be in kerberos-lib-dev right ?

In D39758#1182965, @ivy wrote:

is this still relevant? i don't think it's correct (anymore): the first kernel in KERNCONF is always installed to /boot/kernel because that's where the default kernel is expected to be. changing that would require updating a load of stuff (like loader) to look somewhere else instead.

In D51756#1182294, @ivy wrote:

it's a bit of an odd package since there's no reason to install it at all unless you're hacking on src, and i'm not sure we have any precedent for that. does it make sense to have a FreeBSD-src-man package? there are a few more things that we could perhaps move there, like src.conf(5). however, we'd need to make it not depend on FreeBSD-src.

Not sure if clibs is the best package for this, maybe it fits better in runtime (which have libutil.so and the man in the -man) ?