In D21733#475785, @imp wrote:

In D21733#475782, @ryan_freqlabs.com wrote:

while we've transitioned to teken, it looks like it eats the ESC c

Ok, that looks pretty tough to deal with. Now that you mention it, I'm not seeing colors on the EFI serial console either, and under bhyve the scroll region is broken after the loader hands off to the kernel as well. It's everything I wanted to fix, still broken! Ugh! I thought I had tested that, but I guess I only tested a video output with the EFI console.

It is the most maddening part to get right... It's why I never upstreamed my hacks that I knew didn't work.

One way of dealing with this could be to add a variable to bypass teken for users of serial EFI consoles. A more challenging but perhaps more flexible option would be to implement a driver for the EFI serial protocol and either expose it as something like "efiserial" console or maybe add special handling to the existing EFI console driver to duplicate ANSI sequences to the serial port.

I actually think that's quite hard and involved. The current code doesn't differentiate, unfortunately. It would take a little while to understand a good path forward. At the moment, I see parsing ConOut, looking up handles and using that in something complicated, but there may be something simpler...

I don't think solving that problem with the EFI console/teken is within the scope of this change, though I am certainly hoping it gets fixed. I've only learned of teken's existence a few days ago. Can someone more familiar with that piece provide their input on the issue?

This can really only work for comconsole. And even there it can only be imperfect. And people will complain and expect me to fix it, so I'm reluctant to sign off until we have a better notion of a path forward...

In D21733#474205, @kevans wrote:

Hmm... on second thought, this might need tested with a black-on-white xterm. I seem to recall having to spit out color.default() because we couldn't cope with the different background color and kept screwing up @emaste's xterm. I'm assuming this will put us back into that state, and we'll need to have the color.default() back after the reset.

In D21655#472098, @bcran wrote:

Actually yes, this change isn't correct. See https://github.com/tianocore/edk2/blob/master/MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c for an example of how to allocate aligned memory (InternalAllocateAlignedPages etc.)

Yes, this fix is not complete. We should always use "bounce buffer" here and only use aligned memory. Of course the disk write is also broken here (unless I'm mistaken)...

review suggestions from illumos.

About the EFI_HTTP_Config_Data:

read vim_entries by chunks.

Implement OpenProtocolByHandle()

In D21162#459738, @imp wrote:

love the idea, but think it would be better to create a centralized location where we wrap this.
Call me paranoid, but I fear there may be a EFI bios we need to do this for :(
But also, it will make the code easier to read, so win/win.

also chain /boot/loader.efi does not complain about network any more. network boot seems to be all ok too.

In D20319#443365, @p.bruenn_beckhoff.com wrote:

Agreed, a sane vdev_probe() would be nice. But I have totally no idea how you want to omit cleaning up partially initialized spa/vdev objects without rewriting the whole file. Either some of the current error paths are dead code or things like vdev_init_from_nvlist() have to be replaced.

In D20319#442667, @p.bruenn_beckhoff.com wrote:

Yes, but not for all failures. If a label is found in the loop but later the associated data found invalid the vdev_probe() will fail even if there would be another label with better data.

Something is off there. The for loop in vdev_probe() does continue in case of failures, but is intended to walk through all 4 labels, so why do we fail?

There is problem now. The zfs_alloc was "always" succeeding but malloc can fail, therefore we can not just replace here, but we also need to add checks.

LGTM