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

[Ivan Gyurdiev <ivg2@cornell.edu>]

>What do you expect from the callbacks? 
>
That's a good question - I'm not entirely sure. I guess that's why I'm 
trying to push the issue outside the library so we don't have to make 
that kind of decision.

It's important, IMHO, that the user not be forced to use stdout/stderr 
for debugging. I think both approaches accomplish that. Then it's 
important to allow the caller to recognize which thread created the 
problem - that's Joshua's concern. This means that we *need* 
caller-supplied state at the point of debugging, or we can't accomplish 
this (whether that's the address of a per-thread buffer, or whether it's 
the thread ID available to a callback function, or whatever).

The issue of callback vs buffer is less important - I guess it seems 
more flexible to me to have a callback function, instead of having to 
worry about allocating buffers, looking inside the buffers, deallocating 
buffers... but if you disagree we can use buffers.

>They can certainly do simple
>things like drop the entire message based on level, drop the function
>name information, etc, but constructing an overall error message that is
>presentable to the client/user from the entire set of DEBUG() calls
>seems difficult.
>  
>
Yes, I wouldn't expect the callback to have the logic to do that - 
that's just a question of policy on how you use the debug system in your 
code, and at which point you issue error messages.

>>If we design the debug system properly, we can handle any usage pattern, 
>>including this one.
>>    
>>
>
>True, but if this is the only usage pattern (in addition to the default
>one of writing all DEBUG output to the user and not using the error
>buffers at all for single-threaded users), then it seems overkill.
>  
>
Which part, specifically, seems like overkill?




--
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.