My initial proposal was posted as comments to #2713,
https://condor-wiki.cs.wisc.edu/index.cgi/tktview?tn=2713,0
switching to an enum rather than widening gives us more room now
and makes it easier to have the number of flags grow as our needs grow.
The idea has been refined since then in discussions with Zach and Jaime,
but the basic idea is the same.
There is also a older ticket by psilord
that captures some of the same ideas.
https://condor-wiki.cs.wisc.edu/index.cgi/tktview?tn=1025
but rather than psilord's suggestion of second parameter, I'm proposing
to mix flags and the enum together into a single value as the first
arg of dprintf
and have the dprintf back-end code split that back into category,
verbosity, and other flags
before operating on it.
Since none of the current tickets fully captures the proposed
solution, I'm thinking
I should make a new ticket with the new proposal. I'll post back when
it's in place.
In any case, the proposal depends on having clients of dprintf keep
their hands off the global
variables that dprintf uses to decide whether a message should get
printed, so the first
step in the patch would involve putting a macro layer between the code
and the globals.
I think that part should happen regardless of how we eventually decide
to refactor the D_xxx flags.
-tj
