LGTM

In D47846#1090926, @imp wrote:

yea, the only question I have is if we move all the assembly values into machine/intr.h, duplicating one or two across architectures and include machine/intr.h for the assembler, or if I leave it as I have it inthe review. @jhb

In D47831#1091595, @br wrote:

In D47831#1091588, @mhorne wrote:

I strongly think this should be a newbus device driver. Unless there is some urgent need that it should be set up at SI_SUB_CPU?

This driver needed before threadinit() otherwise tid_alloc() won't work. It is needed even all cache ways in ccache driver are disabled (however the way 0 is always enabled). May be it flushes other L1/L2/L3 caches I am not sure, but from I saw the freebsd could not use memory that was just allocated in tid_alloc() without a flush. So this should go anywhere before SI_SUB_INTRINSIC.

In D47831#1091588, @mhorne wrote:

I strongly think this should be a newbus device driver. Unless there is some urgent need that it should be set up at SI_SUB_CPU?

This driver needed before threadinit() otherwise tid_alloc() won't work. It is needed even all cache ways in ccache driver are disabled (however the way 0 is always enabled). May be it flushes other L1/L2/L3 caches I am not sure, but from I saw the freebsd could not use memory that was just allocated in tid_alloc() without a flush. So this should go anywhere before SI_SUB_INTRINSIC.

I strongly think this should be a newbus device driver. Unless there is some urgent need that it should be set up at SI_SUB_CPU?

text LGTM, I'm not familiar with this markup flavour tho.

Add linuxulator section

In D46653#1091534, @igoro wrote:

In D46653#1091513, @ngie wrote:

For the record, stuff like this should really be committed to freebsd/kyua first, then backported. As of right now this change is not in what's intended to go in to 0.14 and in order to do the upgrade I would need to reapply this patch. I provided a ship-it earlier, but I was swayed by the comment in the PR about this change being confusing for naive results parsers: https://github.com/freebsd/kyua/pull/230 .

Yeah, ideally it should go through the GitHub repo. I tried to help with the synchronization by keeping this review and the GitHub PR in sync, the latter was expected to be "blindly" merged after all approvals on the Phab, unfortunately I do not have access to do that. Probably, we could think of some access for me? My vision is that I could merge the things like that PR after all discussions and approvals on the Phab side.

In D46653#1091513, @ngie wrote:

For the record, stuff like this should really be committed to freebsd/kyua first, then backported. As of right now this change is not in what's intended to go in to 0.14 and in order to do the upgrade I would need to reapply this patch. I provided a ship-it earlier, but I was swayed by the comment in the PR about this change being confusing for naive results parsers: https://github.com/freebsd/kyua/pull/230 .

Sorry about that, actually test building the change :)

In D46301#1079978, @melifaro wrote:

I'm going to come up with a different version of this patch (likely using a new flag rtmsg->rtm_flags to signal RTM_F_FORCE) in a day or two. The current version allows all netlink customers to fully bypass PINNED route protection, which defeats its purpose.

For the record, stuff like this should really be committed to freebsd/kyua first, then backported. As of right now this change is not in what's intended to go in to 0.14 and in order to do the upgrade I would need to reapply this patch. I provided a ship-it earlier, but I was swayed by the comment in the PR about this change being confusing for naive results parsers: https://github.com/freebsd/kyua/pull/230 .

And when that is changed, please ask for an exp-run to see if things break.

Not really sure what to do with SND_USE_FXDIV and SND_DECLARE_FXDIV. Also I will write some follow-up patches to clean up the drivers as well.