[sane-devel] SANE 1.1.0 Debug Levels

[Olaf Meeuwissen]

"m. allan noah" <kitno455 at gmail.com> writes:

> Ok- how about we start a separate thread for each major topic that
> needs discussing...
>
> Olaf has suggested that we split image data off into a different
> level. So I've gotten rid of the calibration level. These may not
> match what you guys need for your backends, so please make
> suggestions....

Actually, the raw image data is just the most typical type of info
that would produce heaps of debugging data that is of virtually no
use when debugging.  Sending firmware files or calibration data are
others.

The idea is to have an alternative level for that kind of bulky
debugging data.

> 1 DBG_LVL_ERROR      (errors only)
> 2 DBG_LVL_WARNING  (recovered errors)

You seem to imply the DBG_LVL_ERROR is for the unrecoverable errors.
If that is the case, I would think the user *always* wants to know or
*always* should be informed.  A level of zero might be appropriate.

We have the various SANE return status values to indicate some errors,
but several times I've found these to be either not informative enough
(the backend can tell much more precisely what's wrong but the status
just doesn't let you) or lacking (when I can't quite find a suitable
status, of course I can't think of any right now :-().

> 4 DBG_LVL_FUNCTION (function tracing 'enter xxx()' or 'exit xxx()')
> 8 DBG_LVL_DETAIL      ('trying action X' or 'action succeeded' etc)
> 16 DBG_LVL_OPTION   (any sane_option parsing code)

Doesn't this correspond to DBG_LVL_DETAIL?  As in parsing option this,
setting option that, ...

> 32 DBG_LVL_COMMAND (dump data packets sent to scanner)
> 64 DBG_LVL_RESPONSE (dump data packets read from scanner, other than image)

For my part, I would always want to see the pair of command and
response in the debug log, so I don't see the need to separate these.

> 128 DBG_LVL_IMAGE   (dump image data read from scanner)
>
> I have also been thinking about the security risk of those backends
> that open files and write out data at certain debug levels, how about
> we use a 9th bit for that, so that most users will never accidentally
> do it?

IIRC, the debug level can only be set in a *portable* manner to a
value in the [0,127] range, ends inclusive.  This has something to do
with the way certain shells handle environment variables, but I don't
remember exactly where I got that idea.  I think somewhere in the GNU
Standards.

If that really is the case, bit fields for the levels are not a good
idea.

While you mention security risks, the image data might qualify in that
department.  Imagine the embarrasment if I were to send a debug log to
the list that included the image data for a page of the ESC/I spec ;-)

Users need to understand what is included in the debugging data that
they send you (or the list).

Hope this helps,
-- 
Olaf Meeuwissen                   FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962           sign up at http://member.fsf.org/