Update copyright:

review feedback.

missed included header.

drop hw accelerator related code.

Testing done: did create dataset with compression=gzip, did copy some text files on it. verified from loader with command 'more', those files are readable.

thanks!

I think this is good change, thanks.

There is this nagging question however - should we check the return value from snprintf (like in this last instance). We do know those strings should fit (normally), but if there is non normal case of memory corruption...

Hm, it seems, we do not need f in any of those instances? Should we just remove that argument?

Seems good to me, thanks.

In D34539#782504, @imp wrote:

In D34539#782503, @kevans wrote:

In D34539#782502, @imp wrote:

It looks like this is used only as a fallback...
And IIRC, this has been required since 2.0 and would only be wrong on things like old core/core2 macbooks.
Where is this failing?
And maybe we should look at what we do for libefi...

As of the 2.9 spec, table 2-11 in 2.6.1 does not list either the from/to text protocols as required elements. No objection to centralized handling if we do it elsewhere, too.

So it does...

I've held off on this in the past because I also entertained the idea of switching the EDK2 APIs so we can also pull in ACPI parsing...

The whole point of color and font (and mode) setup is to provide consistent console from loader to kernel to user land.

Sure, I was just starting the pickup, if you could mail me git format-patch output, it would be great (So I would get the author and date correct).

Good catch.

In D33598#759117, @manu wrote:

In D33598#759115, @tsoome wrote:

I think, we probably should allocate shadow fb outside of heap (for UEFI loader, with BS->AllocatePages()), however, this is a bit complicated with BIOS loader.

In the meantime even using a 1280x1080 screen is enough to break tftp preloading so I don't see some quicker solution.

I think, we probably should allocate shadow fb outside of heap (for UEFI loader, with BS->AllocatePages()), however, this is a bit complicated with BIOS loader.

Thanks.

I haven't seen any wrong happening from it either.

I was starting to think.... we do have read ahead buffer (f_rabuf) in struct open_file, perhaps we could extend that interface to accommodate preload data?

In D33411#755311, @manu wrote:

In D33411#755273, @tsoome wrote:

I think, this should be generic command - it would do for any filesystem read.

Sure, like "read" ?

I think, this should be generic command - it would do for any filesystem read.

Sorry for making it messy:D

In D33302#752740, @imp wrote:

What does 'first' mean? It's effectively a random list, in random order since there's no boot priority indicated. Why would you prefer something random here? What if there are two or three? This can lead to weird behavior.

I'd prefer if we preferred, where possible, the ZPOOL that has an element from the current disk we're booting from first, with a fallback to anything else marked as bootable since that's less unpredictable.

So I have some concerns.... With luck, one of the ZFS people will say there can be only one or something...

I'd guess the same issue is with VBE.

Thanks for doing this:)

In D32249#728568, @cperciva wrote:

In D32249#727706, @tsoome wrote:

It does feel wrong to have two if (complete) blocks in a row, perhaps it isworth to factor ra update out to separate function at some time...

I considered that, but since this is the only place we adjust bc->ra it seemed like an unnecessary complication to add a new function; at least now the changes are collected together in one place.

The entire function could probably do with being refactored and/or restyled, but that seemed like something which could wait.

It does feel wrong to have two if (complete) blocks in a row, perhaps it isworth to factor ra update out to separate function at some time...

The obvious flaw is about possible unfreed memory, but that shouldn't be big problem anyhow.

In D32172#726049, @kevans wrote:

Advise that only the presence of a value matters

In D32227#727121, @bz wrote:

Is it limited to aarch64 or general EFI netbooting?