Date: Fri, 6 Nov 1998 16:53:57 -0700 (MST) From: "Kenneth D. Merry" <ken@plutotech.com> To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: CAMDEBUG change to mull over... Message-ID: <199811062353.QAA03708@panzer.plutotech.com> In-Reply-To: <Pine.LNX.4.02.9811061211140.3059-100000@feral-gw> from Matthew Jacob at "Nov 6, 98 12:15:12 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Jacob wrote... > > On Fri, 6 Nov 1998, Kenneth D. Merry wrote: > > That's not surprising at all. :) > > > > > What do you think about CAM_DEBUG_XPT flag that will allow this > > > to be traced separate from other tracing? > > > > Well, we could do that, but I'd rather have a little more generic solution > > that would allow turning on/off tracing for various modules or drivers. > > > > I.e., have something that would let you just turn on tracing for the sa > > driver, or just for the transport layer, or just for the error recovery > > code in cam_periph.c/scsi_all.c, or for all modules... > > > Well- if this is the case, let's nuke CAM_DEBUG_PRINT (at least as it is > currently used in cam_xpt.c- it really has to be used only sparingly or > you'll never be able to find this debugging any use at all) and allow a > set of arbitrary cam paths to used for debugging being enabled. The xpt > layer itself has a path (CAM_XPT_PATH_ID). I think it's fine to trim down the number of CAM_DEBUG_PRINT statements in cam_xpt.c. The transport layer path is -1, which is also used to turn on debugging for all busses. I'd rather come up with something separate from cam_path statements to specify which files/modules you want debugging info from. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811062353.QAA03708>