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?

I think, it is still not set early enough; you want to have it set up before we run devsw probes.

In D4713#722510, @cperciva wrote:

Sorry to re-review something from five years ago, but I had a question about this code...

In D29961#721453, @greg_unrelenting.technology wrote:

In D29961#721288, @tsoome wrote:

In D29961#721194, @greg_unrelenting.technology wrote:

ping. someone please commit?

Could you mail me git format-patch?

Done (sent to the freebsd.org address). Also updated it here, though "Download Raw Diff" still extracts a small diff anyway :/ Seems like only arc can apply patches with the message and everything from phab.

In D29961#721194, @greg_unrelenting.technology wrote:

ping. someone please commit?

added support for more file systems.

Thanks!

Other than those few nits, it seems to be good (I hope the hw tests will also confirm;)

Ok, after some thinking, I did realize, we need to restructure this code some more. The problem is, pxe_netif_receive() should return complete Frame unless there is nothing coming, but UNDI ISR can end up in different states, and in some cases, we would want to receive again. Or to put other way - the current implementation is using pxe_netif_receive() as interrupt routine for UNDI, but UNDI interrupt and pxe_netif_receive have different semantics.

In D30848#713814, @cperciva wrote:

Can this be committed now, with other mount/unmount capabilities added later?

I think, https://reviews.freebsd.org/D30848 should improve your use case even more.

implement mount/unmount for dosfs.

update cd9660 to have mount/unmount.

add zfs_mount and zfs_unmount.

more comments.

Addressing first round of comments and suggestions.

This is complete rework. Instead of hacking into not releasing
bcache, we "mount" filesystem (if supported) while we set "currdev"
environment variable. By mounting, we create open disk device and we
do keep it open till this file system will get unmounted, and the
bcache segment for this devei is preserved.

This is something I was suspecting to happen:) Still need to read the resulting code carefully. Which method was used to load kernel, tftp or nfs?

Suggestions from imp.

As suggested by imp

Thanks!

Seems good, thanks!

In D30848#694017, @cperciva wrote:

This also returns with pd->pd_blkio set to non-NULL. Is this intentional?

do not set pd_blkio to NULL.

In D29512#662063, @yongbo.yao_dell.com wrote:

In D29512#661895, @tsoome wrote:

Since md case is depending on build options and is not part of generic build, this feature should not generate problems for general public. I do agree, it should get documented. Do we want to provide feature parity with i386 tree (BIOS loader)?

Thanks Toomas. I suspect that this feature is rarely used in legacy BIOS so did not add it in i386 tree. But I'm fine if you think it's worth to be added.

Since md case is depending on build options and is not part of generic build, this feature should not generate problems for general public. I do agree, it should get documented. Do we want to provide feature parity with i386 tree (BIOS loader)?