linux-kernel - Re: [PATCH 0/2] small xhci cleanups

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ada1vfh6z6a.fsf@roland-alpha.cisco.com>
Date:	Thu, 18 Mar 2010 15:30:05 -0700
From:	Roland Dreier <rdreier@...co.com>
To:	Greg KH <greg@...ah.com>
Cc:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	Alex Chiang <achiang@...com>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] small xhci cleanups

 > > I think the end user doesn't want to see anything from the driver unless
 > > something serious has gone wrong.  But those cases use xhci_warn(),
 > > which translates down to dev_warn(), instead of xhci_dbg().
 > 
 > Yes, that's fine.  But you need/want something for when a user reports a
 > problem, and they can't rebuild their kernel.

Yes, just to be clear (and I'm pretty sure I'm agreeing with Greg here)
any warnings that you want always enabled to show something in the
kernel log whenever there's a problem should be dev_warn() or
equivalent.

Things that produce too much output and that you only want on when
you're debugging a problem are probably best done via trace events.

 - R.
-- 
Roland Dreier  <rolandd@...co.com>
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/