Page MenuHomeFreeBSD

Add an option for specifying the default debug flags for mps driver.
AbandonedPublic

Authored by imp on Apr 4 2019, 3:53 AM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 22 2023, 11:38 PM
Unknown Object (File)
Nov 5 2023, 9:24 AM
Unknown Object (File)
Nov 5 2023, 8:22 AM
Unknown Object (File)
Nov 2 2023, 4:00 AM
Unknown Object (File)
Oct 30 2023, 3:57 PM
Unknown Object (File)
Oct 4 2023, 8:18 AM
Unknown Object (File)
Oct 2 2023, 6:33 AM
Unknown Object (File)
Sep 30 2023, 8:20 AM
Subscribers

Details

Reviewers
slm
scottl
Summary

Rather than requiring someone hack mps.c to set these, make them a
proper option.

Test Plan

Build w/o this option, and build with options MPS_DEBUG_FLAGS in a kernel config.

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 23527
Build 22531: arc lint + arc unit

Event Timeline

imp added a reviewer: scottl.

If this looks good, I'll do the identical changes to mpr as well.

Why not just cut straight to a tunable instead and save a compile?

ScottL will want a matching change to dev/mpr (if appropriate) to keep them in sync.

Edit: oops, got our lines crossed. I see you plan to do so:

In D19816#424989, @imp wrote:

If this looks good, I'll do the identical changes to mpr as well.

In D19816#425165, @cem wrote:

Why not just cut straight to a tunable instead and save a compile?

Sometimes the deployment is just easier to compile it in. There's a default with /*XXX */ (which I need to change) which suggests that its useful. This has been the debugging default for a long, long time, though...

imp edited the test plan for this revision. (Show Details)

mps debug flags in NOTES, as appropriate.

I debated tossing this into sys/conf/NOTES, but didn't want to play whack-a-mole with the architectures that I'd opt out of... Comments?

Eh, I'm not a big fan of this, converting the driver to use strings from sysctl and kenv was intended to make it as easy as possible to set and unset flags from the default. It also adds new touch points in the system that will have to be updated or risk going stale if debugging evolves. Is editing, compiling, and deploying a new kernel easier than editing loader.conf? That said, I don't have a hard objection to it being committed, so long as the first time it goes stale, Warner buys me a nice chopped brisket dinner at Shorty's.

On second thought, I'll use the tunable.