This is actually wrong. HYPERV should be added to BROKEN_OPTIONS on !x86.
But there's already 3 other bad offenders :(

How were you able to determine this?
The latest version of Linux doesn't have this quirk.

This year's award for going above and beyond in testing goes to...

What does this do that
sysctl -n kern.geom.conftxt
doesn't do?
Seems like this is just filtered information from that data source.
At the very least, a pointer to that information should be given since it's so much easier to use in scripts than this output.

Generally I like this, but it also looks like there's some drive reset retry logic tossed in as well...

In D6814#362680, @ian wrote:

In D6814#155355, @stevek wrote:

In D6814#155318, @andrew wrote:

This should be attached to the build, and used by the GNU dtc.

I'm wondering should libfdt be conditionally built and, if so, should it be based on MK_FDT and MK_GPL_DTC (since the dtc build will be using it after the suggested changes)?

I think it should be conditional on MK_FDT, but not on MK_GPL_DTC, because the library itself is BSD-licensed.

Looks good to me. I could nit-pick all day at this stuff, but I'd rather get this in and cope with the nits after the release.

looks good, as does the good humanize_number catch.

I listed both because different applications require different numbers.
Sometimes you need SI stuff since you are more familiar with that stuff due to there aspects of your pipeline (eg disks or networks)
Other times you want the IEC ones because you (eg memory images)
It's also not burdensome to do both, just tricky to get the code right...

rS338402 Sr338402 fixes this. Said differential review, not differential revision.

Thanks for the context, I'll update the commit message and submit to re@

I think you can get around the edge case of dlclose by using setjmp/longjmp as outlined.

Regen latest tree

• Put building of drm and drm2 modules behind options.
• Add big, nasty abandonware tags to this code.

btw, the 4th ask is just an ask, not a must have

Now all we need to do is get Devin to add it in forth and we'll be set :)
1/2 :)

Seems straight forward enough... Not sure this is the right layer to put this functionality.
lemme cook on this.

In D16894#360433, @johalun0_gmail.com wrote:

LGTM and I assume there's another patch coming that will fix the loader issues?

I think I've done all the actionable items in this review.

• Add big, nasty abandonware tags to this code.

Rod comments

cem's suggestions and WITH*DRM stuff

• Put building of drm and drm2 modules behind options.
• Add big, nasty abandonware tags to this code.

In D16870#359353, @rgrimes wrote:

I respectfully request that a straight revert of the commits be done rather than this, for one this does not allow us to do the proper deprecation commits, nor to merge those commits back to stable/11. This is still a major violation of deprecation policy. Warner, would you new policy allow this type of thing to be accepted? I would hope not.

Furthermore this differential is failing build, something we do not want hours before code freeze!

There's three files that matter here, given my plan: sys/conf/Makefile.arm, sys/arm/conf/TEGRA124 and sys/arm/nvidia/tegra124/files.tegra124
The rest are just copies from dev/drm2 before the rm.

mmel's fix looks good to me.

• nomatch

need to update a comment, but otherwise looks good.

• Improve devmatch driver loading
• Remove sorting of matches and print all the matches as we find them.
• Stupid debug
• fold kernel
• Add a new device flag: DF_ATTACHED_ONCE
• When trying to match the nomatch event passed to us, attempt to look
• Implement blacklisting for devmatch
• Mark nomatch devices

These optimizations look sane to me, but I've not spent a lot of time studying it for subtle effects.

In D16815#358214, @arichardson wrote:

In D16815#358213, @imp wrote:

In D16815#358212, @arichardson wrote:

In D16815#358208, @imp wrote:

How does this interact with LOCAL_XTOOL_DIRS? Doesn't this totally break that feature?

As far as I can tell LOCAL_XTOOL_DIRS is only added to the cross-tools list of subdirectories so it should just work (unless the build of LOCAL_XTOOL_DIRS depends on another tool that is not in $PATH)

A trivial test case would be nanobsd:

cd tools/tools/nanobsd/embedded ; sh ../nanobsd.sh -c qemu-amd64-uefi.cfg

which uses the feature to build mkimg.

Thanks, I'll try that and update the patch if necessary.

In D16815#358212, @arichardson wrote:

In D16815#358208, @imp wrote:

How does this interact with LOCAL_XTOOL_DIRS? Doesn't this totally break that feature?

As far as I can tell LOCAL_XTOOL_DIRS is only added to the cross-tools list of subdirectories so it should just work (unless the build of LOCAL_XTOOL_DIRS depends on another tool that is not in $PATH)

How does this interact with LOCAL_XTOOL_DIRS? Doesn't this totally break that feature?

blacklist
don't reload unloaded drivers, part 2