In D44670#1018389, @jrtc27 wrote:

Why do we need a copy of this code rather than just tweaking bsdconfig to support this?

Also updated bin/freebsd-version/freebsd-version.1.

In D42433#968563, @imp wrote:

remove /sys

Focus on D42146 instead.

This updated diff:

Should I rebase this patch since D42194 is already merged?

I rebased and updated the commit with the full message at https://github.com/khorben/freebsd-src/tree/khorben/tzsetup-extra.

Thanks; this is now ready to merge from https://github.com/khorben/freebsd-src/tree/khorben/bsdinstall.

(I did not mean to remove any reviewer, I guess I re-used an old browser tab without refreshing)

This is in the khorben/bsdinstall-netconfig branch at https://github.com/khorben/freebsd-src/.

This is in the khorben/bsdinstall-netconfig branch at https://github.com/khorben/freebsd-src/.

This is also related to #192194.

(If you don't mind)

Imported in 315108b81694de474bbc273c0050b195047f5eed.

• This now uses break to be more future-proof
• The commit message now mentions the change in behaviour when selecting unknown actions

• Made "Finish" the default action
• Renamed the "OK" button to "Select"

In D42047#959636, @jrtc27 wrote:

Every additional keypress required, especially ones for navigating to the right option, makes an already user-hostile installer have even more friction. I am very strongly opposed to not being able to quickly skip through screens that 99.999999% of users do not need.

In D42047#958942, @jrtc27 wrote:

Is the new Finish button selected by default?

Replaced by D42046 and D42047.

In D41945#958461, @emaste wrote:

test for existence of file before removing

to avoid spurious errors

Looks good to me.

Sounds good to me then!

I found information confirming my doubts about the keccak code.

Can you review the comment I added about crypto/sha/asm/keccak1600-armv8.pl?

We may also want to consider 40c24d74deaad8a0ad7566a68ea5ea757bc3ccef as well, from OpenSSL's Git repository:

FWIW this patch does not conflict with the import of OpenSSL 3.0.11 that I am currently preparing (vendor import in D41943).

I have the impression that with these changes, pxeldr will fail to build if MK_LOADER_LUA is not enabled. I am preparing a new patch where SUBDIR_DEPEND_pxeldr+= loader_lua_nozfs is protected by .if ${MK_LOADER_LUA} != "no", but then pxeldr is still hard-coded to L=loader_lua_nozfs; that feels wrong.

Also build aes-586.S for i386.

• Created a single new loader variant, loader_lua_nozfs
• Hard-coded the PXE loader to use loader_lua_nozfs instead of loader_${LOADER_INTERP}

Submitted again after rebase on -CURRENT.

You are right, with a better look I also see differences with the SHA512 files.

• Renamed the new member of struct country
• Use a switch/case for pass 1 to 3

In my tests the output is identical with and without this revision, except for avoiding the generation of temporary files on i386.
ISTM that the same optimization is possible on arm64, arm, and powerpc{,64,64le} as well by the way; would you consider applying it there as well?
Here is how I test locally: (from secure/lib/libcrypto)

#!/bin/sh

To me this looks tidier and also more sensible than before; indeed, why did it set the suffix to .pl only to remove it and add it again?

In D41298#940467, @jrtc27 wrote:

If you're moving code around and modifying it at the same time, please make two commits / revisions so it's much easier to review what's going on. Otherwise you have to flick back and forth between files.

Re-upload with arc this time (for context)

In D41250#939437, @khorben_defora.org wrote:

In D41250#939432, @mhorne wrote:

FYI: D40142

I do not know what the hesitation is there, but I know several people would prefer to see this menu disappear completely.

Thanks, I wasn't aware of this proposal. I can probably improve this patch some more, so that the default settings from the current installation are reflected.

Respect the original copyright for the "finalconfig" code.

Fix the brief summary in the commit

In D41293#940281, @emaste wrote:

review heading is wrong?

In D41250#939538, @jrtc27 wrote:

Or let's just let this abomination of a menu finally die...

In D41250#939432, @mhorne wrote:

FYI: D40142

I do not know what the hesitation is there, but I know several people would prefer to see this menu disappear completely.