Looks good to me. pcs-handle is not used on non-SerDes (i.e. RGMII) MACs.

Fix kernel_boothdr.lua file mode.

Added riscv linker script change missing in previous revision.

In D10335#568530, @jhb wrote:

I think this is fine now at least for the lib9p bits as next commit (i.e. everything except usr.sbin/bhyve which I still think should be a 3rd commit).

Once it's committed it would be good to refresh with the latest version of the bhyve bits.

Clean up makefile.

Revert back to previous concept (sort of).

In D10335#547251, @jhb wrote:

Can you refresh this with the updating lib9p/Makefile you plan to use?

In D10335#539242, @jhb wrote:

Well, do we think the GH will still be used once this is imported? If we think only FreeBSD will use this and that it will be fine to just live as a FreeBSD library then importing into lib/lib9p is fine and there's no need for the other bits that would get dropped. The argument for not doing vendor was that we didn't have a real upstream. If we have a real upstream, then it needs to be in contrib/.

BTW, even in upstream I think the issue of which files contain bits from libipx is probably still relevant and it would be good to update the per-file copyright statements to ACK that library in the relevant files.

In D10335#539175, @jhb wrote:

So assuming a non-contrib model, the library needs to look like it is a normal base system library. This means no separate COPYRIGHT file, no README.md file, no GNUmakefile or apple_endian.h. Each file needs an accurate copyright statement. I think all the files do, but none of them mention libipx mentioned in COPYRIGHT, so if libipx bits are used, then the files using those need to have a proper attribution in their license statement.

Removed contrib/lib9p/ and moved all lib9p sources under lib/. Consolidated two Makefiles (upstream contrib/lib9p/Makefile and local lib/lib9p/Makefile) into one.

In D10335#516241, @jhb wrote:

So this looks good to me, but the latest upload lost all the lib9p sources. I finally found the lib9p upstream, though the only version I see is in your GitHub space? I would be fine with still using that as an upstream though and putting the sources into contrib/lib9p (despite the last call where I said it could move). I think it would be good to first import lib9p into the vendor/ space and then contrib/, then a commit to hook it up to the build (being able to hook the tests up to run as part of the kyua test suite runs would be a bonus), and finally the commit to add it to bhyve 3rd.

• Sort lib9p SRCS in the Makefile
• virtio-9p: error out on invalid options.

Updated missing lib/Makefile changes

Added bsd.libnames.mk and src.libnames.mk changes left out in previous update.

Proposed changeset passes make tinderbox run:

Fixed issues pointed out in the review. Added full read-only sharing support.

This update adds the Capsicum/Casper support to lib9p. It definitely needs more polishing, though.

In D10335#214339, @emaste wrote:

Is there another upstream repo where you'll maintain lib9p? I'm slightly surprised to see bespoke code landing in contrib/

In D10335#214061, @grehan wrote:

Any thoughts on the interaction with capsicum ? Seems like you just need blanket access underneath a particular directory.

still missing: man page changes. working on them...

Fixed issued pointed out by mav@, added new switches to usage() in ctladm.c

I can't really comment on style, but from technical accuracy standpoint it's all good.

Added -d switch to ctladm port command to specify frontend driver type (default is ioctl). Fixed resource leaks in cfi_shutdown(). Fixed minor gratuitous typecasts. Added seatbelts preventing default ioctl port to be destroyed.

I decided to not allow to destroy default ioctl port

Fixed various things pointed out by reviewer.

Adapted to new ramdisk backend features, added fragments missing in previous diffs

Fixed several HEAD mismerges

I'd be glad to hear what else needs to be changed - I applied that patch in freenas/os tree about a month ago and heard from several users that it fixed virtio-blk on Windows for them, but maybe they didn't push it hard enough.

There might be some merit in implementing guest side of emergency write feature - virtio spec says that emergency writes are possible even before device is initialized or even reset, and emergency write port resides inside PCI config space, making it easy to write to it from loader(8) or during kernel early initialization.

Port names are not null-terminated - putting '\0' at the last byte was wrong.

Cast basename() argument to char *.

Style fixes; moved check_perms() after parse_conf()/uclparse_conf().

Initialize "tag" variable to NULL explicitly at uclparse.c:134.