In D22792#499038, @rpokala wrote:

In D22792#499018, @imp wrote:

You should rename btxldr/Makefile to be btxldr/Makefile.inc
You should create a new btxldr/Makefile that (1) installs btdldr.8 and (2) create a symlink to btxldr from the default interpreter.

I presume s/btxldr/pxeldr/g throughout that comment?

In D22785#499016, @chuck wrote:

While I don't have an issue with this change per se, if the goal is to support nvme-cli, I'd argue that it would be better to provide an emulated device node via the Linux compatibility layer. The main concern is nvme-cli assumes it operates under Linux which exposes NVMe devices to the system in a very different way to what FreeBSD does (e.g. device node naming differences, device nodes are block devices, etc). Thus to better support nvme-cli, there would probably be additional IOCTL's added here to support / work-around Linux-isms. And these additions would look odd as nothing in base would use them.

You should rename btxldr/Makefile to be btxldr/Makefile.inc
You should create a new btxldr/Makefile that (1) installs btdldr.8 and (2) create a symlink to btxldr from the default interpreter.

update, per kirk

So long as you commit to fixing any bugs we find later, I think we're OK.
The only other code that might be an issue is the part editor. I think it might do the right thing, but if you have the means to test it with your change, that would be great

Looks mechanical

.Dd bump is the only thing I see...

Fix typos in comments from review.

also note, there's a lot here, but for the commit I'll break it down smaller.

In D18351#445683, @mckusick wrote:

Has this been resolved / committed?

rebase

I'll take a look at this and make sure my setup still work w/minimum of hassle.

In D22598#496759, @scott.benesh_microsemi.com wrote:

In D22598#494456, @imp wrote:

In D22598#494383, @jhb wrote:

@sbruno Do you have a PoC for this driver?

IIRC, it was from HP. But I'm not sure how well PQI with SOP has been accepted in the marketplace...

Well, we seem to be selling lots of cards. :) I'll have the developers update our code base and test out these changes.

Sorry for the delay... this looks good to me.

assuming it passed portlint and this was part of a poudriere build, it looks ready.

assuming it passed portlint and this was part of a poudriere build, it looks ready.

assuming it passed portlint and this was part of a poudriere build, it looks ready.

assuming it passed portlint and this was part of a poudriere build, it looks ready.

This looks generally good to me, modulo my one comment. I assume that it also passes portlint since I didn't do that myself.

Nice catch

In D22660#495654, @jhb wrote:

Probably this should be on for all soft-float architectures. I'd rather pull in Makefile.float from https://github.com/freebsd/freebsd/commit/eb836f75fe342c01a51bba1c96abacd448fabc88 and use that to set this rather than add all the combinatorics though. This has also only been observed on riscv to date.

Looks same to me. The only macro difference is dropping the idle thread check. Is that intended? Is so, is it safe?

In D22598#494383, @jhb wrote:

@sbruno Do you have a PoC for this driver?

I'll look at this more, but I think you need obsolete files updates.

I would have been tempted to put parents around all macro args while l was at it...

Not seeing any holes here

Other than printing a warning here to help debugging should the alloc fail, I think this is good.

Looks good to me

Looks good to me. Other commands use different flags to run in foreground, though. IT's inconsistent...

Thanks for your patience with me for delays in my end.
Looks good and I think we're good to go.

Running a final make universe before committing.
Should be in tomorrow morning if nothing breaks.

LGTM

This looks better to my eye.

Go for it!

If we are nailing this struct down, this does that.