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)?

In D29020#655703, @manu wrote:

In D29020#655696, @emaste wrote:

@tsoome will you commit?

I planned to do it last weekend but this was delayed for this week. I'll probably do that tomorow.

In D29126#652263, @chuck wrote:

I'm having trouble matching pci_nvme.c:903 to current, stable/12 or stable/13. Which branch is this? I'm curious to see why the compiler doesn't like this instance as (naively) everything should be nicely aligned.

In D29126#652257, @chuck wrote:

I'm happy to help out on the NVMe part but don't see this warning while building x86_64 on current. Can you point me in the direction of how to reproduce this?

You want to add the same to vbefb.