netdev - Re: [PATCH] SMSC LAN9500 USB2.0 10/100 ethernet adapter driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <200809100947.36480.david-b@pacbell.net>
Date:	Wed, 10 Sep 2008 09:47:36 -0700
From:	David Brownell <david-b@...bell.net>
To:	Steve.Glendinning@...c.com
Cc:	Catalin Marinas <catalin.marinas@....com>, ian.saturley@...c.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH] SMSC LAN9500 USB2.0 10/100 ethernet adapter driver

On Wednesday 10 September 2008, Steve.Glendinning@...c.com wrote:
> 
> > Standard feedback for such stuff:
> > 
> >  - avoid printk() for diagnostics, use dev_*() driver model calls
> >  - ... or in this case, pr_warning() if you really must
> >  - provide better messages and avoid passing __func__ 
> >  - use inline functions instead of CPP macros
> >  - make dead code elimination remove debug code, not #ifdefs
> > 
> > And specific to network devices:
> > 
> >  - use the ethtool message level flags not private debug_mode
> 
> There's quite a bit of variation on the debugging style across existing 
> drivers.  Is there any driver you would suggest to use as an example of 
> how to do things right?

Not without searching through a lot of code ... though you
can have a look at <linux/devices.h> dev_dbg() to see how
to use inlines to make sure diagnostic code always gets
type checked and make dead code elimination behave.

So then it'd be "if (netif_msg_FOO(...)) dev_dbg(...)" for
debug messages; or pr_debug; etc.  The thing that's truly
bad about most printk/pr_* type diagnostics is that they
usually don't identify the relevant device, or if they do
then it's not done consistently.

Last time I did a network driver I found that I only wanted
to use those driver model calls before the network device
was set up ... a message tagged with the interface name was
a lot more useful than one tagged with the physical device,
so long as there was an initial banner coupling the two (a
dev_info message printing the interface name along with a
hardware summary).

- Dave
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html