From: Nishanth Menon <nm@ti.com>
To: Ionut Nicu <ionut.nicu@mindbit.ro>
Cc: Greg KH <greg@kroah.com>, "Sapiens, Rene" <rene.sapiens@ti.com>,
Ionut Nicu <ionut.nicu@gmail.com>,
Omar Ramirez Luna <omar.ramirez@ti.com>,
Fernando Guzman Lugo <x0095840@ti.com>,
Felipe Contreras <felipe.contreras@gmail.com>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
linux-omap <linux-omap@vger.kernel.org>
Subject: Re: [PATCH v2 08/12] staging: tidspbridge: convert rmgr to list_head
Date: Sun, 07 Nov 2010 08:24:10 -0600 [thread overview]
Message-ID: <4CD6B68A.5010107@ti.com> (raw)
In-Reply-To: <1289131884.9931.166.camel@atlantis.mindbit.ro>
Ionut Nicu wrote, on 11/07/2010 06:11 AM:
> Just out of curiosity, in what cases is it acceptable to use
> BUG_ON/WARN_ON?
here is my rule for BUG_ON Vs WARN_ON:
imagine this code to be running on your Phone while you are doing
sometime important, and this case gets hit - choose:
a) you stop the entire phone - BUG_ON
b) provide a cryptic info - WARN_ON - just the func name with not much
additional data
c) provide detailed info : in the order of my personal preference:
dev_dbg/dev_info/dev_err/... -> if there is anychange of getting to the
struct device * representing the device
pr_err/pr_info/pr_warning -> if there is no other alternative
keep in mind - few months from now, code would change, function line
numbers change etc.. - I'd usually NOT TOUCH BUG_ON, NOT use WARN_ON
unless I am threatened by maintainer, and choose one of (c) based on the
location in the code I am at..
I know that some folks think that when a case is reached, they'd like to
do a BUG_ON so that the issue is caught and fixed immediately - SORRY, I
disagree as I see the code running in a endproduct - and BUG_ONs cause
system hang and reboots in an end product - which as a personal user of
a great Linux phone like N900 is definitely not my personal preference.
--
Regards,
Nishanth Menon
next prev parent reply other threads:[~2010-11-07 14:24 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-05 15:13 [PATCH v2 00/12] staging: tidspbridge: various cleanups Ionut Nicu
2010-11-05 15:13 ` [PATCH v2 01/12] staging: tidspbridge: remove gs memory allocator Ionut Nicu
2010-11-05 15:13 ` [PATCH v2 02/12] staging: tidspbridge: remove utildefs Ionut Nicu
2010-11-05 15:13 ` [PATCH v2 03/12] staging: tidspbridge: switch to linux bitmap API Ionut Nicu
2010-11-05 15:13 ` [PATCH v2 04/12] staging: tidspbridge: remove gb bitmap implementation Ionut Nicu
2010-11-05 15:13 ` [PATCH v2 05/12] staging: tidspbridge: rmgr/node.c code cleanup Ionut Nicu
2010-11-05 15:13 ` [PATCH v2 06/12] staging: tidspbridge: convert core to list_head Ionut Nicu
2010-11-05 21:07 ` Sapiens, Rene
2010-11-06 17:21 ` Ionut Nicu
2010-11-08 19:15 ` Sapiens, Rene
2010-11-05 22:12 ` Sapiens, Rene
2010-11-06 17:31 ` Ionut Nicu
2010-11-08 19:16 ` Sapiens, Rene
2010-11-05 15:13 ` [PATCH v2 07/12] staging: tidspbridge: convert pmgr " Ionut Nicu
2010-11-05 22:41 ` Sapiens, Rene
2010-11-07 13:39 ` Ionut Nicu
2010-11-08 19:17 ` Sapiens, Rene
2010-11-05 15:13 ` [PATCH v2 08/12] staging: tidspbridge: convert rmgr " Ionut Nicu
2010-11-06 0:07 ` Sapiens, Rene
2010-11-06 18:18 ` Ionut Nicu
2010-11-06 18:26 ` Greg KH
2010-11-07 12:11 ` Ionut Nicu
2010-11-07 14:24 ` Nishanth Menon [this message]
2010-11-07 15:59 ` Greg KH
2010-11-08 19:18 ` Sapiens, Rene
2010-11-05 15:13 ` [PATCH v2 09/12] staging: tidspbridge: remove custom linked list Ionut Nicu
2010-11-05 15:13 ` [PATCH v2 10/12] staging: tidspbridge: core code cleanup Ionut Nicu
2010-11-05 15:13 ` [PATCH v2 11/12] staging: tidspbridge: pmgr " Ionut Nicu
2010-11-05 15:13 ` [PATCH v2 12/12] staging: tidspbridge: rmgr " Ionut Nicu
2010-11-05 15:43 ` [PATCH v2 00/12] staging: tidspbridge: various cleanups Greg KH
2010-11-05 16:02 ` Ionut Nicu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CD6B68A.5010107@ti.com \
--to=nm@ti.com \
--cc=andy.shevchenko@gmail.com \
--cc=felipe.contreras@gmail.com \
--cc=greg@kroah.com \
--cc=ionut.nicu@gmail.com \
--cc=ionut.nicu@mindbit.ro \
--cc=linux-omap@vger.kernel.org \
--cc=omar.ramirez@ti.com \
--cc=rene.sapiens@ti.com \
--cc=x0095840@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.