From owner-freebsd-firewire@FreeBSD.ORG Wed Jun 9 11:31:59 2004 Return-Path: Delivered-To: freebsd-firewire@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9B9416A4CE for ; Wed, 9 Jun 2004 11:31:59 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (80-219-172-121.dclient.hispeed.ch [80.219.172.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0F8C43D2D for ; Wed, 9 Jun 2004 11:31:57 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:50db:ac79:0:250:daff:fe5a:2107]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id i59BVm645965 verified NO); Wed, 9 Jun 2004 13:31:53 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id i59BVl445964; Wed, 9 Jun 2004 13:31:47 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Wed, 9 Jun 2004 13:31:47 +0200 (CEST) Message-Id: <200406091131.i59BVl445964@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL To: Hidetoshi Shimokawa From: Barry Bouwsma References: <200406080857.i588vo301522@Mail.NOSPAM.DynDNS.dK> <87y8mxcviz.wl@tora.nunu.org> cc: FreeBSD Firewire Developers Subject: Re: orb pointer printf() question X-BeenThere: freebsd-firewire@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Firewire support in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2004 11:32:00 -0000 Hidetoshi Shimokawa wrote: > > SBP_DEBUG(0) > > printf("%s: orb pointer active\n", __func__); > It's harmless. > I believe that the default level of debugging is 0 and > the DEBUG(0) clauses is not executed. *slaps forehead* Ooops! You're right, setting sysctl debug.sbp_debug to 0 quieted those messages. I should have known. I boot -v verbosely, which sets the firewire debug levels to 1, so that I can get verbose info from other hardware. I had noted that the amount of boot messages, and also the firewire debugging (not sbp) during normal operation, were far too high for my taste at debug level of 1. Therefore, I patched the source to set firewire_debug to 0 even with verbose booting. I did not think to check that sbp might have inherited the debug level of 1. (I did not think it was much too verbose by default, though.) Hmmm, this reminds me of something that I have wanted: because verbose booting is my default, I'd prefer if the debug level of 1 that it sets, is used by sbp/firewire_debug for a similar level of verbosity during boot -- perhaps a bit less for sbp, and I believe a lot less for firewire. Certainly during normal operation, I don't think either one of these should be sending harmless console messages like this after a verbose boot. And probably, a verbose boot can be a bit less verbose for sbp/firewire than now. (I know, I can rc.sysctl these levels back to 0 after boot is complete, but I still feel boot itself is too verbose, which is why I changed my source.) Can I propose that the present DEBUG() levels be increased by one, and then only the more important ones for verbose booting be restored to 0? This way, verbose boots can still give a bit more info than the default non-verbose 0, and for those who want it, setting the sysctl to 2 will give the present amount of detail. The hard part would be selecting the DEBUG(1)s that should be restored to DEBUG(0); I could easily make a patch that increments all the values by one... If there is a plan to rework the debug levels in the firewire code (I think I may have read that, some time ago), then please ignore my idea above. Sorry for my stupidity. Thanks! barry bouwsma