Re: [ SEPOL ] Move more things to newer debug system

[Ivan Gyurdiev <ivg2@cornell.edu>]

Stephen Smalley wrote:

>On Sat, 2005-09-17 at 23:52 -0400, Ivan Gyurdiev wrote:
>  
>
>>I'm not sure we need both a filtering mechanism, and two systems - one 
>>for debugging and one for error reporting.  That looks like redundancy 
>>to me. I think we need to choose one debug system, add a filtering 
>>mechanism to it, and convert everything to use it. The filtering 
>>mechanism would then determine what's done with the different types of 
>>messages (which are not too clear at the moment).
>>    
>>
>
>I viewed it more as:
>- drop the notion of level/priority since you explained how you can't
>truly classify the different DEBUG messages into those categorizations,
>  
>
I was saying that I'm not convinced you can consider the lowest-level 
message of type ERROR, and the ones above it in the call chain of type 
DEBUG. A different classification system might work, however... the 
level argument could be useful.

>- don't clutter a single interface trying to support both variants, just
>keep them as separate interfaces,
>  
>
We could easily move the level argument into the function name (support 
WARN(), ERROR()), etc.

>- recognize that both DEBUG and write_error are doing error reporting,
>but with differing feedback mechanisms (global callback vs. per-call
>error buffering) and with differing levels of detail.
>  
>
This is the important part - do we want to keep both feedback 
mechanisms, or not.
If the former, then yes - we should keep both write_error and DEBUG. 
However, I think
that's not necessary, because if we implement callbacks, and add a state 
object to pass to
the callbacks, the user of libsepol/libsemanage can design any error 
system they feel like,
which is more flexible than making that choice in the library.

Regarding the differing levels of detail - the callback can make that 
decision if we provide it
with the level of  message (error/debug..etc).

>I expected to use DEBUG() pervasively as the default mechanism, and only
>selectively insert write_error calls (and extend interfaces to take the
>buffers) as needed to support the specific needs of the policy
>management daemon.  Policy management daemon would then disable the
>DEBUG output or redirect it to a log file and only feed the buffered
>error messages back to the client.
>  
>
If we design the debug system properly, we can handle any usage pattern, 
including this one.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.