HTCondor Project List Archives


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Condor-devel] dprintf changes in master

Lag...with lots of questions...

I assume the intention is to have :n include :0...:(n-1)...:n.
I'm concerned it will be difficult for someone writing configuration to know what :n to include, especially if the code uses a different language, i.e. config has D_ALWAYS:2 and code has D_ALWAYS|D_VERBOSE. Will you add a :SYM, where SYM can be mapped to the appropriate n? Say :VERBOSE -> :2. FYI, it isn't clear what :1 is other than not-:2. Ideally, the verbosity levels are ordered and no :n is needed.
That brings me to - are there any places in the code where we've tried to have more than two levels of verbosity, i.e. more than D_VERBOSE and not-D_VERBOSE?
I'm also concerned about a layer in the code that's doing "D_* | D_FULLDEBUG" -> "D_*:VERBOSE | D_ALWAYS:VERBOSE" unless D_* has a :. What about leaving all D_* as they are. We'll add D_*|D_VERBOSE to the code over time and users can start using D_*:VERBOSE over time. It means that, for most D_*, D_*:VERBOSE is redundant to start, but I don't see much wrong with that.
How are the formatting flags specified in configuration? I'm imagining something like CATEGORY:VERBOSITY/FORMAT, but maybe format flags apply across the board. 

Best,


matt

On 06/25/2012 03:49 PM, johnkn@xxxxxxxxxxx wrote:

in config D_SECURITY:2 means D_SECURITY:VERBOSE. In a dprintf call this
would be expressed as D_SECURITY | D_VERBOSE.  To avoid a lot of call site
changes, a dprintf call with D_SECURITY | D_FULLDEBUG will be translated
as D_SECURITY | D_VERBOSE inside the dprintf code.

also for backward compat, in config D_SECURITY | D_FULLDEBUG is converted
to D_SECURITY:2 | D_FULLDEBUG unless there is an explicit :n in the config
line.

note that in old config D_FULLDEBUG acts as _both_ a category and a
verbosity modifier on other cats.

the new config code treats D_FULLDEBUG as meaning D_ALWAYS:2 and also as
:2 for every other mentioned category unless any category uses the new :n
syntax

any integer is accepted after the : it represent the desired verbosity.
formatting flags are not allowed. currently only :1 and :2 are useful.

i expect future 7.9 changes to include 8 bits of verbosity control for
each category in dprintf internal data structs. current transitional impl
is 2 bits with binary 11 meaning the same as 10.

formatting flags have already been split into a new 32 bit member.

the intent of changes is to facilitate future increases of verbosity
levels, category codes, and formatting flags.


On 05/31/2012 11:53 AM, John (TJ) Knoeller wrote:

This morning I pushed to the master branch a combination of Z's changes
to allow for multiple output destinations from dprintf,
and my changes to convert most of the dprintf 'flags' into an enumerated
set of categories.
see https://condor-wiki.cs.wisc.edu/index.cgi/tktview?tn=2933 for more
information.

These patches change many of the internal global variables that dprintf
uses and that a lot of code used to party on directly. In
particular, you can no longer change the DebugFlags global variable and
expect dprintf to react.

The good news is that there is now more room to add new output
formatting flags (like D_PID), and also more room for new categories.
Current implementation allows for 32 categories and 32 flags. we
currently have 26 categories and 10 flags. I expect Zs future changes
to increase the the limit on the number of categories substantially.

The bad news is that any given message can be assigned to only 1
category.

dprintf (D_SECURITY | D_COMMAND, ... )

Is no longer allowed. since these are both categories. We don't do this
in any current code, but it used to be OK if you did. now
you get unexpected results. D_SECURITY is 1011 binary, D_COMMAND = 1100
binary so this is effectively the same thing as sending 1111 binary
which is dprintf (D_KEYBOARD,

For backward compatibility D_FULLDEBUG gets a lot of special case
behavior, both in the code, were it is defined as a verbosity flag. so
dprintf(D_SECURITY | D_FULLDEBUG, is still allowed. and

dprintf(D_FULLDEBUG

is interpreted as

dprintf(D_ALWAYS | D_VERBOSE.

It is now possible to configure the verbosity output level of each of
the categories individually. so in condor_config you can say

SCHEDD_DEBUG = D_FULLDEBUG D_SECURITY:2 D_COMMAND

This will give you verbose D_SECURITY and D_ALWAYS, but non-verbose
D_COMMAND output. This was combination was
impossible to express before. In parsing condor_config D_FULLDEBUG it is
used as a _global_ verbosity modifier unless
the new syntax is used, so

SCHEDD_DEBUG = D_FULLDEBUG D_SECURITY D_COMMAND

gives verbose output for D_ALWAYS, D_SECURITY and D_COMMAND, just like
always because the new syntax is NOT used.

-tj


Will you explain :2, as in D_SECURITY:2? What are valid values, is it
like D_SECURITY:D_FULLDEBUG or maybe D_SECURITY:D_VERBOSE, how does the
code target D_SECURITY:2 vs D_SECURITY:300.

Is formatting assignable to a category, e.g. D_COMMAND:D_PID?

Best,


matt