Are we eventually going to do something with the com_speed, other than write to it just for printf sake?

I hope so. We should set hw.uart.console based on this. However, we're missing bits to do that. If comconsole_pcidev is set, we need to find it one way. If we have comconsole_port set, we know directly. Trouble is, both of these variables are set later so we can't count on them here. And they are only set for comconsole, console not efi console. We could get this information from ACPI, but that's a tree walk, and I'm not really keen to include that.

We likely could do something in the EFI console to export this information, since I think it's set late enough to peek at these variables. But even that looks to be tricky w/o some careful study.

So, enshrine the code here for now, and work on exporting it in a follow on commit.

This seems to have snuck in unused

Yea, it's a merge error from a later patch.

I think setting both means that serial is preferred which may be surprising for folks if a normal desktop box advertises both serial and video as the console as this will effectively turn off the video console post-boot.

(See shenanigans related to RB_SERIAL handling in stand/boot/i386/libi386/bootinfo.c where RB_SERIAL is turned off if "vidconsole" is first)

Debug?

Perhaps rather than RB_RESERVED1 have parse_uefi_con_out() return a boolean and accept howto by reference:

if (parse_uefi_con_out(&howto)) {
    setenv("console", "efi", 1);
} else {
    /* existing code to set "console" */
}
bootenv_set(howto);

This would move the merging into parse_uefi_con_out() by having it construct the temporary it already does and then do the merge stuff before 'return (true)' or the like. I think the code flow would be simpler and read better (and avoid abusing RB_RESERVED1).

Unrelated?

Correct. However, there's no way to know which is first at this point...

This does, however, make the kernel messages actually appear on both, which is what we want in this case.

The real solution, however, is to support a real /dev/constty that is the union of all the active ttys.

yea...

I'd dispute it's an abuse: it's supposed to be fore a boot loader defined purpose :)

But it wouldn't be a bad restructure.

Yes and no. We never should have set this.

Mix of '#define<space>' vs '#define<tab>' (style(9) is to use tab)?

Fixed.