Thanks and sorry about this.

This will also affect -CURRENT no ? (but it's also better to use weekly by default here)

In D54289#1242003, @imp wrote:

I'd still be tempted to put it in files and just spike 32bit builds. Sure, you can put it in the config file and yhe error is delayed until you build, but that's ok imho. Lots of things in files that don't work evertwhere. No need for a files.64.

In D54289#1241834, @kgalazka wrote:

The module will build only on 64-bit arch (amd64 and powerpc64 was already there, this patch adds arm64). I don't think it was ever tested on 32-bits, and I don't have too many spare cycles to look into that.

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 ?