• fix C++ style commments
• Use clang-format to get consistent style

rebased, should be ready for review now

I can confirm that cross-building from macOS still works with this patch. I have a slight preference for keeping symlinks in the ${.MAKE.OS} != "FreeBSD" / -DNO_ROOT case but keeping stuff consistent is more important.

In D25967#575752, @imp wrote:

In D25967#575683, @arichardson wrote:

In D25967#575682, @imp wrote:

In D25967#575668, @arichardson wrote:

Copying instead of creating links *should* be fine. However, I vaguely seem to recall this previously caused issues for bootstrapping macOS since one tool wanted to find something relative to realpath argv[0]. Will check if that's still the case tomorrow morning UK time.

Sure thing. I included you because I had hoped to get this perspective. On Mac/Linux, only the incompatible tools need to be bootstrapped, and they will use $HOST libraries always, no?

Yes, and they default to BOOTSTRAP_ALL_TOOLS.

So they never use the host native binaries once bootsrapped?

In D25967#575682, @imp wrote:

In D25967#575668, @arichardson wrote:

Copying instead of creating links *should* be fine. However, I vaguely seem to recall this previously caused issues for bootstrapping macOS since one tool wanted to find something relative to realpath argv[0]. Will check if that's still the case tomorrow morning UK time.

Sure thing. I included you because I had hoped to get this perspective. On Mac/Linux, only the incompatible tools need to be bootstrapped, and they will use $HOST libraries always, no?

Copying instead of creating links *should* be fine. However, I vaguely seem to recall this previously caused issues for bootstrapping macOS since one tool wanted to find something relative to realpath argv[0]. Will check if that's still the case tomorrow morning UK time.

remove file that wasn't intended for this change

D25416 has been committed. Any objections to me committing this?

@alfredo/ @fernando.valle_eldorado.org.br Are you planning to commit this soon?

Minor grammar suggestions but otherwise looks good to me. Thanks!

ping?

In D25416#569712, @fernando.valle_eldorado.org.br wrote:

@arichardson Which freebsd .img revision are you using?

In D25416#569712, @fernando.valle_eldorado.org.br wrote:

@arichardson Which freebsd .img revision are you using?

I can confirm that this makes virtio-rng work again for MIPS64. LGTM if you apply @alfredo's suggestions.

address review comments

Add TMPFS to all kernel configs instead

If no one objects I'll commit this patch later this week.

In D25662#567794, @mjg wrote:

manpage refers to the string and needs to be updated

Also update manpage

In D25229#563871, @emaste wrote:

collate.c looks like an independent bugfix you can just commit first?

use a single make target

avoid unncessary diff to makefile

New approach that avoids modifying public headers

I stepped through MIPS init in QEMU and it turns out MALTA ends up with

p sc->vtpci_res->r_bustag
$7 = (bus_space_tag_t) 0xffffffff809aefc0 <gt_pci_space>

In D25217#559400, @jhb wrote:

I'm not sure it makes sense to commit this until it works?

In D25317#559146, @jrtc27 wrote:

In D25317#558621, @arichardson wrote:

In D25317#558618, @jrtc27 wrote:

Why are we doing this for GENERIC? No other architecture does so, and the only differences between them for GENERIC should be genuinely architecture-specific things, which TMPFS is not. If you want it for MFSROOT kernels, limit it to those. GENERIC is supposed to pick it up as a module just like everything else not required during earlyish boot.

arm/GENERIC has include "std.armv7" which enables TMPFS

True, and perhaps for similar reasons of being used on (somewhat-)embedded devices. Honestly I don't know why it _isn't_ always compiled in.

In D25317#558618, @jrtc27 wrote:

Why are we doing this for GENERIC? No other architecture does so, and the only differences between them for GENERIC should be genuinely architecture-specific things, which TMPFS is not. If you want it for MFSROOT kernels, limit it to those. GENERIC is supposed to pick it up as a module just like everything else not required during earlyish boot.

In D25312#558211, @pstef wrote:

I'm in favor of the change. However, it's been pointed out to me in the past that with all object declarations at the start of the function body it's easier to reason about the stack.

In D25210#556616, @jrtc27 wrote:

Patching the in-tree Clang to default to -mno-relax for FreeBSD might make sense. But out-of-tree can be used with BFD so that's not upstreamable.

In D25210#556612, @jrtc27 wrote:

That test doesn't show anything, we know the flag is required by default, and there's no easy way for Clang to know what your linker is at compile time (it doesn't get LDFLAGS normally, and you don't know what /usr/bin/ld is).

Not sure what arc did here with copied from. Those are new files not copies.

In D23401#555947, @arichardson wrote:

In D23401#555913, @fernando.valle_eldorado.org.br wrote:

@arichardson Could you say what is the complete command you use to run this vm on qemu? (./qemu-system-mips64 -M malta (...) what else?)
I reversed this commit and compiled the kernel and would like to test it according to your environment.

I have the following patch to enable virtio for std.MALTA (uploaded as D25217):

diff --git a/sys/mips/conf/std.MALTA b/sys/mips/conf/std.MALTA
index 26940db1b92f..787b3962caea 100644
--- a/sys/mips/conf/std.MALTA
+++ b/sys/mips/conf/std.MALTA
@@ -55,3 +55,13 @@ device               miibus
 device         bpf
 device         md
 device         uart
+
+# VirtIO support
+device         virtio          # Generic VirtIO bus (required)
+device         virtio_pci      # VirtIO PCI device
+device         vtnet           # VirtIO Ethernet device
+device         virtio_blk      # VirtIO Block device
+device         virtio_mmio     # VirtIO MMIO bus
+device         virtio_random       # VirtIO RNG
+device         virtio_console      # VirtIO Console
+

Then I use
qemu-system-mips64 -M malta -m 2048 -nographic -kernel /home/alr48/cheri/output/freebsd-mips/boot/kernel/kernel -drive file=/home/alr48/cheri/output/freebsd-mips.img,format=raw,index=0,media=disk -nic 'user,id=net0,ipv6=off,smb=/exports/users/alr48/sources -device virtio-rng-pci to boot.

This works for me, but it freezes on startup if I have this change included.
I use the following (probably incorrect) patch to allow it to compile on MIPS since bs_be_tag doesn't exist there:

diff --git a/sys/dev/virtio/pci/virtio_pci.c b/sys/dev/virtio/pci/virtio_pci.c
index aba35eb38ff5..7b48b771c417 100644
--- a/sys/dev/virtio/pci/virtio_pci.c
+++ b/sys/dev/virtio/pci/virtio_pci.c
@@ -297,7 +297,7 @@ vtpci_attach(device_t dev)
  * other parts of this file via functions
  * 'vtpci_[read|write]_header_[2|4]'
  */
-#if _BYTE_ORDER == _BIG_ENDIAN
+#if _BYTE_ORDER == _BIG_ENDIAN && defined(__powerpc__)
        rman_set_bustag(sc->vtpci_res, &bs_be_tag);
 #endif

In D23401#555913, @fernando.valle_eldorado.org.br wrote:

@arichardson Could you say what is the complete command you use to run this vm on qemu? (./qemu-system-mips64 -M malta (...) what else?)
I reversed this commit and compiled the kernel and would like to test it according to your environment.

In D23401#554153, @afscoelho_gmail.com wrote:

In D23401#554073, @arichardson wrote:

This commit appears to have broken using QEMU MALTA (MIPS64 BE) with -device virtio-rng-pci.
With this change I get an infinite loop on boot that goes away if I revert it:

I tested -device virtio-rng-pci with qemu-system-ppc64 and had no issues. Some questions:

• Did you use -global virtio-pci.disable-modern=on ?

I just tried and this flag does not seem to make any difference, it also hangs.

• If you don't use -device virtio-rng-pci it works?

Yes, it works in that case. If the device isn't there it doesn't use vtrnd_harvest()

• What is the compilation error?

sys/dev/virtio/pci/virtio_pci.c:301:34: error: use of undeclared identifier 'bs_be_tag'

In D25154#554275, @emaste wrote:

In D25154#554268, @arichardson wrote:

The other option would have been to change the build system to pass -Wa,-defsym, SKEIN_USE_ASM=XXX (that's what I did for my godbolt testing.
But either solution seems fine.

Oh hmm, I tried that and had an error, but now I see I tried --defsym with two dashes.