What debug level should libnet run at?

[Andrew Bartlett]

Having sorted out the issues with -d and 'net', I wondered what debug
devel libnet really should operate at, for library users.

The history seems to be that originally, libnet operated at debug level
0, enforced by a:
DEBUGLEVEL=0 in the libnetapi_init() function.
http://gitweb.samba.org/?p=samba.git;a=commitdiff;h=749f699f871831e9ad5b2a57e498a32f959d23c6

Then in
http://gitweb.samba.org/?p=samba.git;a=commitdiff;h=77a25318105d90ae34a05c8a1e71df84343bb28e
diff --git a/source3/lib/netapi/netapi.c b/source3/lib/netapi/netapi.c
index 47b3ba9..fb091f6 100644 (file)
--- a/source3/lib/netapi/netapi.c
+++ b/source3/lib/netapi/netapi.c
@@ -50,7 +50,9 @@ NET_API_STATUS libnetapi_init(struct libnetapi_ctx
**context)
                return W_ERROR_V(WERR_NOMEM);
        }

-       DEBUGLEVEL = 0;
+       if (!DEBUGLEVEL) {
+               DEBUGLEVEL = 0;
+       }

        setup_logging("libnetapi", true);

        dbf = x_stderr;

As I read it, this means that if DEBUGLEVEL was 0, then it was reset to
0 (ie, a no-op).  The original log level of 1 would apply, as far as my
reading shows (the default, as the smb.conf was not allowed to override
it). 

Now after my debug changes in
http://gitweb.samba.org/?p=samba.git;a=commitdiff;h=cf4de8ec2c8df2ceabbe3d836d296b058e7b19fb, for libnet users we now unconditionally set it to log level 0 (ie, the original behaviour), until API callers set otherwise. 

I think it's a reasonable thing, and what was originally intended but as
this changes an API behaviour (back) I just wanted to check that it's
all OK. 

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20101125/524ae42f/attachment.pgp>