Date: Thu, 23 Sep 2010 14:06:56 -0700 From: Pyun YongHyeon <pyunyh@gmail.com> To: David Christensen <davidch@broadcom.com> Cc: Tom Judge <tom@tomjudge.com>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: bce(4) un hiding adapter info Message-ID: <20100923210656.GE15014@michelle.cdnetworks.com> In-Reply-To: <5D267A3F22FD854F8F48B3D2B52381933B5A78B55C@IRVEXCHCCR01.corp.ad.broadcom.com> References: <4C9B8A50.9060602@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933B5A78B444@IRVEXCHCCR01.corp.ad.broadcom.com> <20100923182033.GA15014@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B52381933B5A78B55C@IRVEXCHCCR01.corp.ad.broadcom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 23, 2010 at 01:48:13PM -0700, David Christensen wrote: > > > What I'd really like to do is revamp the debug code so that it > > > can be enabled/disabled on the fly rather than requiring that > > > the driver be compiled. Adding some performance stuff would > > > > Couldn't it be implemented with sysctl? Users may set a variable > > something like dev.bce.0.diag_bitmap to activate debugging code. > > But it seems that requires a lot of code changes. > > I already have an extensive amount of conditionally compiled > debug code in the driver which uses a bitmap to adjust the > debug spew. For personal testing I've also added a sysctl > to allow that value to be modified at runtime. My concerns > are from a security standpoint (some of the debug code allows > direct register access), a code size perspective (adds a lot Normal users couldn't change a sysctl variable so that information is only available to root(Here I assume the feature is off by default). > of code most people don't use), and the performance penalty I think code size wouldn't be large compared to firmware code. If we switch to use firmware(9) I guess we can reduce the code size a lot. We don't have to carry that image after downloading the firmware. > (lots of bitmap checking even when all debug spew is turned > off). > That's correct. If that checking is not in fast path that wouldn't affect much I guess. > Probably worth the time to pull the most useful stuff into > the production driver and leave the more obscure code in the > debug only build. If there are no complaints I'll add that > to my task list. > > Dave >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100923210656.GE15014>