_Static_assert is in the implementation namespace (_[A-Z]-prefixed), so we are within our right to define this. Whatever libc++ is doing should be made to be compatible; it looks like it's assuming things about the implementation that aren't true.

Without wanting to give a detailed review of the whole thing, I will say that implementing SBI should be done in userspace, it doesn't need to be in the kernel (and really needs to be in userspace to be able to handle the console I/O calls), just like arm64 has PSCI in userspace. You want to just have it send up a VM_EXITCODE_ECALL.

Please use conventional RISC-V IP. For the UART the platform standards want an 8250, and that’s what QEMU’s virt machine provides. For the RTC the goldfish RTC is simple to emulate and what its virt machine uses. If an OS boots on QEMU it should boot on bhyve.

The rest of page table system (including PTE format) is identical.

I feel like if you restructure things you should just be able to use the existing mkisoimages.sh:

Please follow the wiki instructions and be sure to upload full context: https://wiki.freebsd.org/Phabricator#Create_a_Revision_via_Web_Interface

I don't think any of these need to be __extension__({ ... }), you're not using them as an expression, you're using them as a statement, so do { ... } while (0) is perfectly fine.

In D45344#1034535, @garga wrote:

Improved commit message

I don’t understand how this diff relates to the commit message. Whether PASS contains a space or not, using its expansion and deleting its first line are two quite different things.

Though please mention that it's needed for musl in the commit message, otherwise it's not clear why we've been fine without this diff for years

Oh and MFC after?

Though please change your Fixes to be 3bfbb521fef5 ("ls: Improve POSIX compatibility for -g and -n.")

This seems to match what GCC does, though I'm not sure why either need it. Both drivers pass both of -lgcc and -lgcc_s, whether building an executable or shared library (well, testing with GCC 13.2 on arm64 Linux, as that's easily to hand). Can you elaborate on the exact issue you're seeing without this?

It surprises me that GNU ld doesn't want to create canonical PLTs, but avoiding them is reasonable; they are to functions what copy relocations are to data.

It's hard to tell if this was a deliberate design choice or just not thought to be needed when the current UART_FDT_CLASS(_AND_DEVICE) framework was added, but I don't see a good alternative to this. Note that snps and tegra_uart are the only in-tree UART_FDT_CLASS users, and both wrap ns8250.

In D45142#1029592, @jhb wrote:

Drop md.c change

In D45049#1027191, @jhb wrote:

My mental model of what is safe is that it's allowed to move BARs around so long as you disable decoding while you do so, and I'm pretty sure we already do that now to handle FreeBSD kernels (and other OS kernels) that rewrite BARs to size them during boot. We have to avoid trying to register/unregister them while rewriting, and I thought that was driven by if the I/O space was enabled. (See how update_bar_address makes the register_bar call conditional on encoding being enabled.) It sounds like u-boot is just buggy here in that it isn't disabling decoding while it messes with the BARs. This idea is ok though. I wonder if FreeBSD/amd64 boots with this set to true. :)

I believe it's also legal to go and map two BARs to overlap so long as you don't try to access the overlapping range when that's the case? QEMU just maintains a list of PCI BARs and goes for the first one in the list that matches. Allocating the big chunk of MMIO memory statically at the start and just maintaining the list layered on top in PCI code as you mess with BARs seems like it would be a simple, more general fix, and should perform just fine? (Though passthrough may well be "fun" as you mention)

My opinion is that, whilst they are by no means completely unambiguous and fully descriptive, picking a value that's close to right so the user has some idea what the error was even in the absence of error messages is better than just using a hard-coded wholly-meaningless 1 everywhere, as will inevitably happen (and already does when not using sysexits) as a result of this.

In D44883#1023197, @kib wrote:

Does it matter/used on arm64 and risc-v? I remember that psABIs require nx stack always for them. It might be that some (old ?) linker complained about the note on these arches.

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

(The problem this fixes was introduced by me adding profiling to the linker in link_elf_ireloc.)

By ABI break you mean for riscv64sf getting the old symbol versions? That architecture is dead, we should just delete the dead code in the header.

In D44331#1011093, @brooks wrote:

In D44331#1011041, @jrtc27 wrote:

Oh I had it as an in-progress patch to make these *not* inline-only. I don't think it's a bug that they're only inline, but every other architecture exposes them as actual symbols too and GCC at least relies on that. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272759 (comment 5 in particular) and https://cgit.freebsd.org/src/commit/?id=448c505c33cc334193590f3844406d6a74f26e2a.

Ah, I'll grab that and apply it.

Oh I had it as an in-progress patch to make these *not* inline-only. I don't think it's a bug that they're only inline, but every other architecture exposes them as actual symbols too and GCC at least relies on that. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272759 (comment 5 in particular) and https://cgit.freebsd.org/src/commit/?id=448c505c33cc334193590f3844406d6a74f26e2a.

I considered extending the existing riscv_syscon for this purpose, but
it seems better to keep the StarFive/JH7110-specific drivers properly
separated.

In D44207#1009367, @jhb wrote:

ofw_pcib doesn't pass child resources up to simplebus for allocation or activation, it uses bus_space_map directly with a new-bus method to get the bus_space_tag. I think this might be the only one passing SYS_RES_IOPORT up to simplebus and that if this works we might be able to remove all SYS_RES_IOPORT support from simplebus.

s/POSIX files/POSIX text files/

What about all the other PCI controller drivers though? Various use ofw_pcib, for example.

To confirm I understand this: