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

[Ivan Gyurdiev <ivg2@cornell.edu>]

> What I mean is, if there are multiple calls to DEBUG prior to 
> returning to the originating function then there are multiple error 
> messages of varying specificity sitting around somewhere, assuming we 
> even store them all and not just the last one. This isn't ideal for 
> error reporting, but it is for debugging. 

This isn't as clear-cut as it appears. It was never my intent to print 
the call stack for the purposes of debugging. That's why I say DEBUG is 
a misnomer. The reason I print the call stack at every level is exactly 
because you have different levels of specifity, which provide different 
kinds of information, and not always redundancy. The lowest level often 
doesn't make any sense at all, because it is too low-level. The levels 
above it provide context information as to what's going on. The callee 
by itself has no clue of the caller's intent. The caller has doesn't 
understand what the exact error was - they work together. This will 
become more clear with the record engine, which relies on polymorphism - 
the engine would not have a lot of information about what's going on 
with the particular record types. An individual handler working on a 
record would not know what the overall task/query was... a parsing 
helper would know exactly where the invalid input was, but wouldn't know 
what it represents, or why it's important.

That said, I agree that the end result isn't particularly user-friendly. 
It looks similar to what ALSA lib does
when it crashes in mplayer. I'm not entirely sure what should be done to 
fix it.

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