I can not tell much about lua bits, but the rest seems good. I was starting to think if using ! is complicating things (could just use environment variable - those are accessible via kenv), but I'm all good.

In D24920#549167, @oshogbo wrote:

In D24920#549047, @tsoome wrote:

In general, it seems nice. I'd like to see more for description; how the checkpoints would appear, what it means to the boot process, would it mean updates for some manual/handbook? It would nice to refer to zpool, not all people do know where to look for information.

It will appear only if you will if you have checkpoint in the system.
This is small demo: https://youtu.be/Flor6seU080
Please ignore some debug info I already removed them.
Yea probably it is good to update the handbook as well.
I'm never edited the handbook though.

In general, it seems nice. I'd like to see more for description; how the checkpoints would appear, what it means to the boot process, would it mean updates for some manual/handbook? It would nice to refer to zpool, not all people do know where to look for information.

Seems ok.

feedback from cem.

drop crc32 from libsa and use version provided by zlib.

In D24068#529184, @cem wrote:

I’d suggest using the zlib one unless it takes excessive space (bigger precomputed tables, for ex.).

missed stand/uboot/lib/glue.c

In D24041#528666, @greg_unrelenting.technology wrote:

hmm.. The kernel already reads from SPCR (dev/uart/uart_cpu_acpi.c), do we need to feed it duplicate info via comconsole_speed etc.? Or does the i386 legacy bios loader use this info for itself somehow? (I thought env is for the kernel mostly..)

Also, does the setenv("console", "comconsole", 1) mean it's not going to probe vidconsole? (The existence of SPCR should never mean there's no vidconsole ­— I have amd64 and arm64 devices that boot with both an SPCR-defined serial port and a graphical (EFI framebuffer) console at the same time.. )

Wait, that setenv would be overwritten by the ones just after the new biosacpi_detect() call, where the initial_howto & RB_MULTIPLE stuff is.. so is it meant for the case where none of these conditions are true?

In D24041#528666, @greg_unrelenting.technology wrote:

hmm.. The kernel already reads from SPCR (dev/uart/uart_cpu_acpi.c), do we need to feed it duplicate info via comconsole_speed etc.? Or does the i386 legacy bios loader use this info for itself somehow? (I thought env is for the kernel mostly..)

Also, does the setenv("console", "comconsole", 1) mean it's not going to probe vidconsole? (The existence of SPCR should never mean there's no vidconsole ­— I have amd64 and arm64 devices that boot with both an SPCR-defined serial port and a graphical (EFI framebuffer) console at the same time.. )

Wait, that setenv would be overwritten by the ones just after the new biosacpi_detect() call, where the initial_howto & RB_MULTIPLE stuff is.. so is it meant for the case where none of these conditions are true?

feedback from cem.

Suggestions from delphij, thanks!

replace if chain by switch. Print out entire zap_block_type.

In D22139#496705, @greg_unrelenting.technology wrote:

Would it be possible to also support memory-mapped UART this way? Intel >=Skylake and all aarch64 systems use mmio.

I've added an SPCR table to my Kaby Lake laptop to configure the UART, but it would be nice if it could auto configure without SPCR.

Rename comconsole.c to efiserialio.c to avoid issues with libi386/comconsole.c.
On x86, use libi386/comconsole because we still can not ensure the proper order
of serial ports and there is known issue on some systems with input on serial.

really check the device node type. Free unused devpaths by calling
efi_close_devpath().

need to handle usb luns