verbose debugs of socket messages
Paul.Green at stratus.com
Wed May 9 20:45:09 GMT 2001
Jeremy Allison <jeremy at valinux.com> wrote:
> Andrew Tridgell wrote:
> > fine by me.
> > I'd also like to start removing some of our DEBUG() statements
> > sometime. They tend to get added when debugging code then not ever
> > removed, and they add a lot to the size of the binaries.
> I really don't want to do this. They get added as debugging
> code, and become essential when tracking down problems.
> I don't mind making them conditional on compile, but they
> have saved me on many occasions when tracking down 'impossible'
As someone who has been working with Samba for the last year or so, porting
it to a fairly new POSIX layer on our proprietary VOS operating system, and
as someone who has many years of experience working with, and supporting,
systems software, I'd like to offer an opinion here.
I believe that Andrew and Jeremy are actually in violent agreement, but they
may not realize it because they are dealing in philosophy rather than
execution. I agree that the DEBUG() statements are vital but I also think
the volume of messages at high debug levels is stunning, that many messages
report trivial findings, and that some messages omit key information.
Reporting just the right amount of detail from just the right places is an
*art*. I just read the DEBUG statements in source/smbd/reply.c (to pick a
file at random) and I'd say they are well done. I do not understand how the
author decided which debug level to use for each message, and I'm
disappointed that we are using literal integers instead of macros. Perhaps
there is an opportunity here to standardize the level numbers. (Or perhaps
there is a standard and my lack of experience prevents me from spotting it).
The fact that the sheer number of DEBUG statements raises the code size
doesn't bother me, because in a computer with a few hundred megabytes or
more of physical memory, I don't care if smbd is 2 MB or 4 MB or even more
(smbd happens to be about 1.6 MB of code and data on my system). What does
bother me is that when I set the debug level to 10, I get an impossibly huge
volume of output that is difficult to analyze and full of trivial
information. I often know what area I'm having trouble with. I could be more
productive if I could trace, say, password validation without having to
trace everything else.
Given the way in which we collectively support Samba ("set debug level to 10
and send me a trace"), I think it is wise to err on the side of too many
messages. But I would urge us to give careful thought to the best way to
report debugging information, to minimize the number of messages, and to
report significant information with each call. Perhaps we could consider
having broad categories to enable a subset of debug messages (without losing
the ability to trace everything).
S T R A T U S C O M P U T E R
111 Powdermill Road
Maynard, MA 01754-3409 U.S.A.
Senior Technical Consultant
TEL +1 (978) 461-7557
FAX +1 (978) 461-3610
More information about the samba-technical