Change is good, and I like the commit message.

In D56490#1293526, @kib wrote:

In D56490#1293494, @imp wrote:

helps to read exterror(9) carefully <blush>

I did not intended to shame, sorry if it can be read this way. I tried to note that this is specified and is not a tribal knowledge to posses.

really update w/o the extra

This looks good.

helps to read exterror(9) carefully <blush>

reviews

So I'm closing this one... I submitted it twice and there's more on the other ones.

In D56409#1291946, @jhb wrote:

I don't understand how the (struct mbuf *)((uintptr_t)m & mask)) would trigger this? The warnings I had in stand/ with EFI were all legit "casting uint64_t to pointer" or vice versa without a uintptr_t cast, and I fixed those by adding a uintptr_t cast. Presumably the result of the inner expression should be of type uintptr_t and not int? Of course, I'd rewrite those today to use __align_down, then you can do something like: __align_down(m, (~mask + 1)) (but probably the latter is easily to-hand as a constant, e.g. __align_down(m, 16) or the like) without needing any casts (align_down and align_up are type preserving).

There's no issues with _ in driver names unless it gets too carried away: _i_n_t_e_l___t_h_e_r_m_a_l_ would be right out.

In D56467#1292563, @markj wrote:

In D56467#1292560, @royger wrote:

In D56467#1292553, @markj wrote:

This fixes my problem, but if my device wasn't in the puc(4) device table, uart(4) would still try to attach to it and trigger the hang. So, there might still be some problem with the original change. Certainly this is incrementally better, so it's okay with me.

Yeah, puc(4) should likely be expanded to take over any generic PCI UART device with multiple ports? I think it was already broken before my change, as uart(4) would already take over multiport PCIP_SIMPLECOMM_UART_16450A devices. My change expanded that (wrong) behavior to PCIP_SIMPLECOMM_UART_16550A devices also.

Maybe someone more familiar with the PCI serial stuff can provide some guidance whether the puc(4) driver could be made to attach to generic multiport cards? I certainly don't know how to detect those from the PCI config space fields.

Digging a bit, I don't think there's a generic way to detect them. So I'm not sure we can do better.

Can't fault the logic. Wish we could print the address, but it's a lot less important in EFI than in other boot vectors.

So I approve of this belatedly.

So what's wrong with the #ifdef i386 that we're going to tear down in the near future?
This seems to be way over-engineering a solution to a bogus gcc warning.
I'd really rather have #ifdef _KERNEL around the two sat functions instead of this over-engineering.

In D56409#1291371, @jhb wrote:

CHERI is about to break all these anyway. What actual errors are you seeing with the kernel now? When I get armv7 building for GCC we probably want to fix all these properly anyway? So far I'm still trying to get armv7 world building so haven't even looked at the kernel.

I didn't check to see when this regressed. And I didn't do a llvm build (though I should) w/o it.

on second thought, simplify a bit: always write to stdout.

Yea, I'd prefer if we could do

#if sizeof(time_t) == 4
<the code>
#endif

but that's not possible, and i386 is likely the next best thing, assuming it unbreaks the world build on i386.

So this commit shows that the use of this in sys/kern/sys_timerfd.c has been wrong the whole time. We do the math, it overflows, but we can't detect it via these means on i386.

<doh!>
Thanks!

MFC After: 3 days

I thought I had some quibbles with the details here, but thinking about it, these all look good. Go ahead and commit.

Looks sane to me, with the right constants used for the right things.

In D56329#1288884, @michaelo wrote:

In D56329#1288856, @imp wrote:

BIOS is both the generic term for firmware, and the specific term for the old boot interface which was a BIOS. CP/M and many other machines / systems used that. It was only after UEFI came out that the confusion was noticed, too late to do anything about.

Not saying it isn't a good idea to do this, just that EFI BIOS isn't contradictory. But since it's likely confusing to our readers, I'll take a close look.

Thank you, appreciated. From my layman's understanding UEFI is quite complex (see edk2 size) compared to Basic I/O system, and of course both are firmwares.

No. I'll push this.

BIOS is both the generic term for firmware, and the specific term for the old boot interface which was a BIOS. CP/M and many other machines / systems used that. It was only after UEFI came out that the confusion was noticed, too late to do anything about.

I like this, and also @kevans 's suggestion.

In D56249#1287432, @chris.longros_gmail.com wrote:

Drop the watchdog timer change.

Yea. I'd expected approval of one by now... but we'll have to wait a bit for that, so this is perfect.

Current adopted the upstream edk ii headers. Efierr is gone. I plan on mfcing that to 15, i think as the lessor evil.