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.

Looks good. Must have missed these bits when we upstreamed it.

If you moved lfs.[ch] to libexec/flua/modules, then a simple -I addition to CFLAGS and a .PATH would get the job done.

I don't like the lfs.h sharing detail, but it's fine enough we can work out after commit.

I'm cool with the sysctl/tunable naming.. Don't know about TAA enough to comment on the rest :)

In D22147#489200, @brooks wrote:

I think this is ready to go as is. PLIST cleanups can wait IMO.

Seems sane to me, but I'd feel better about getting it committed if others more deeply familiar with the aslr stuff give it their blessing.

This looks like a simple bug fix to me, so I'm inclined to let it in.

I love it now.

Hmmm, does this break native builds for gcc?

I think what we're seeing is that we're running this with the queue unfrozen. This sometimes leads to the race I found because, I think, we run things twice: once in the ccb release path, and then again in the schedule path. The freezes and single stepping has always confused me. Part of the confusion is why we only see this sometimes... How does that come to be...