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

[Ivan Gyurdiev <ivg2@cornell.edu>]

Ivan Gyurdiev wrote:

>
>> I was thinking that unifying them would be ideal, and the callbacks can
>> decide how they want to filter the results.  Just requires that the
>> callbacks be provided with a level indicator in addition to the other
>> arguments that indicates whether it is debug info only or error info.
>> Not unlike syslog(3) or printk(9).
>>  
>>
> Which messages would be marked at what levels?
> Example?


Never mind, you already answered that question.

> Offhand, I don't know of an actual debugging user of DEBUG() yet,
> although it seems that the if (state->verbose) printf statements in the
> Tresys code would qualify as potential debugging users.  There are also
> "informational" cases, like the printfs in policydb_index_others.
> syslog(3) does have distinct notions of debug, info, warning, error,
> critical, alert, and emergency as its priority values.

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

There's the issue of global vs per-function-state. I think the second 
one wins here, and we'll just have to adjust the shared APIs. We could 
create something similar to the semanage handle, which encompasses a 
policydb, as well as error handling. I think libsepol should be the 
library that manages the policydb object.

There's the issue of multiple errors - I think any error system needs to 
support multiple error messages.

Then there's the issue of buffer vs callback. I think callback wins 
here. Provided function-local state, there's no reason not to have a 
callback. If you want buffering services, you can arrange for that in 
the callback. We should add a void* argument to the callback, and keep 
that in the state object, passing it at every invocation.

The function name.... is irrelevant if we go with the callback system - 
callback can drop the name. I think it's useful, and it should stay.

Callback should look something like this, maybe ?
We can write macros to reduce arguments...

int (*DEBUG_v2) (
    void* arg,               /* Caller supplied argument */
    int level,                 /* WARN, ERROR, DEBUG ...kind of like MLS 
level - notion of rank */
    int channel,            /* Wine has this...not sure we need it... 
similar to MLS category - area of debugging */
    const char* fname,  /* Function name */
    const char* fmt,      /* Format string */
    ...)                         /* Format arguments */
   
   










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