Rebase after r354968.

Ping. Can you confirm that this works ok with Linux guests? Also, any sense of making forward progress on using block_if_can_delete()?

Ping.

Ok, I did do some test builds of a "normal" port when testing this as well (just using default PLIST), and I do think it's true that if this broke it would break everything.

I think this probably warrants an exp-run before committing?

There may be better ways of doing this, this was just a first cut. You can see an example of this being used in the child revision in the stack (D22451)

• Use 'if (error != 0)'

A pre-commit hook says I can't commit anything using FLAVORS without portmgr approval, so adding portmgr.

Does this work with GCC? Seems no:

I will make it static for commit.

@emaste would you be able to test this on arm64?

TLS has a similar requirement btw of requiring AAD data that isn't present in the on-wire data in the buffer. The way I would handle TLS if we added support for TLS proper in the ocf_rework branch would be to add a new "mode" CSP_MODE_TLS along with some TLS-specific parameters to the session structure such as the TLS version and the TLS sequence number to 'struct cryptop'. I think that same approach would work well with ESN, but it's a bit invasive for drivers. (One reason I considered CSP_MODE_TLS is that some hardware accelerators such as ccr(4) can do TLS "natively", but that isn't true of ESN AFAIK). I will spend some more time thinking about ESN, but I've just rebased the rework branch and gotten the remaining drivers converted this week, so am going to send out a call for testing today or early next week (I can't run-time test all the drivers). The current framework is far too limited in that real hardware needs to know if it is doing ETA or MTE, etc. and the current OCF has no way to express that. It also has no way to express variable sized IVs (which we really need for the full suite of GCM and CCM NIST KAT vectors). The linked-list approach is also quite clumsy to work with on the driver side (a lot of boilerplate code gets removed from drivers trying to maintain a state machine to validate sessions in the current model that turns into simpler checks on a flat structure in the rework).

I do plan to land my ocf_rework branch soon which completely reworks the data structures (e.g. removing the linked list of cryptoini and cryptodesc). Some pointers to what ESNs are and how they are used would be useful to ensure that the new approach can work with it. The new approach uses a single, flat structure to describe both sessions and operations with explicit modes for combined operations (e.g. an ETA mode for Encrypt-then-Authenticate used by IPSec and TLS with ETM).

• Rebase and update after t4_keyctx.c commit.

Any further thoughts? I could perhaps work on the PLIST thing as a followup and then split up the plist after that

Oh, and yes, for riscv it always ends up as 'riscv64-unknown-freebsd13.0' for both riscv64 and riscv64sf. We add -msoft-float to CFLAGS in bsd.cpu.mk for riscv64sf. I'm not sure if there's a way to encode the float ABI in the target triple. (For 32-bit arm at least there are ABI variants you can put into the triple)

It would be nice if there was some way to centralize this modifier, maybe by using an approach like __LLVM_TARGET_FILT since it is used twice in Makefile.inc1 and twice here. The POWER9 folks have some other review open that centralizes target triple generation I thought, but I haven't looked at it recently.

It shouldn't. The only thing that honors MK_CLANG_IS_CC is the clang Makefile, and during XMAKE we only enter that subdirectory if MK_CLANG_BOOSTRAP is yes, and we shouldn't have both that and MK_GCC_BOOTSTRAP as yes at the same time.

• Enable building of clang by default on riscv.

Note that gdb also knows which symbols have which behavior, so changing the stack frame layout will break kgdb, and then kgdb would have to somehow detect which i386 kernels had which behavior. We've done that once before by peeking at instructions [1], but I think it's not worth spending that much effort on i386 and easier to just let the frame layouts stay as-is. The reason for the enums was to handle the separate cases as you note for args. I don't mind changing this to use 'narg'.

I wish one could use PCPU_GET(gdt) instead of *PCPU_PTR(gdt) to look more readable, but I understand why we can't do that.

I think all you have to do to support multiple files in PLIST would be one of the following in the generate-plist target in bsd.port.mk:

• Move FLAVORS section earlier.

This looks ok to me generally. Do you need to refresh this after other recent commits?

Ping. The kmod.opts.mk change is a prerequisite for bhyve save/restore, so I'd like to either commit that one as-is and do this cleanup afterwards, or get this one unstuck to make forward progress. I still have questions about the KERNBUILDDIR stuff as I don't fully understand the implications of removing those checks.

In D22258#486564, @bapt wrote:

In D22258#486560, @jhb wrote:

Heh, I had thought about just doing this for the ones used by xtoolchain, but this looks more complete.
One thing that might really be nice would be to have an easy way to have multiple PLIST files so that one could have something like:

PLIST_FILES= ${.CURDIR}/pkg-plist ${.CURDIR}/pkg-plist.${TARGETARCH}

And put "common" files in pkg-plist and ARCH-specific files in the sub-plists rather than duplicating lots of plist content. For freebsd6-gcc I used a unified plist with PLIST_SUB's for ARCH-specific files, but having a nice way to have pkg-plist.${FOO} in addition to pkg-plist would be nicer IMO.

Agreed on that, but that requires some work on the framework which I will probably do later, if the use case becomes common ;)

If this permits easily doing something like 'make buildenv; cd rtld-elf32; make' then this really will be nicer than our current approach.

In D22147#486621, @imp wrote:

Nothing caught my eye, though the PLIST is getting to be rather long and a bit of a PITA to deal with :(

@brooks suggested he would consider merging the llvm-xtoolchain ports into the llvm ports as well. I think it is nice that you can 'pkg install <foo>' to get the bits for 'make CROSS_TOOLCHAIN=<foo>'