From: Ian Cowan <ian@linux.cowan.aero>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: clabbe@baylibre.com, mchehab@kernel.org,
gregkh@linuxfoundation.org, mjpeg-users@lists.sourceforge.net,
linux-media@vger.kernel.org, linux-staging@lists.linux.dev
Subject: Re: [PATCH] media: staging: zoran: refactor printk debugging function
Date: Thu, 21 Apr 2022 11:22:00 -0400 [thread overview]
Message-ID: <YmF2mM+Lqv/HOgFl@fedora> (raw)
In-Reply-To: <20220421142153.GA2462@kadam>
On Thu, Apr 21, 2022 at 05:21:54PM +0300, Dan Carpenter wrote:
> On Wed, Apr 20, 2022 at 08:23:16PM -0400, Ian Cowan wrote:
> > This is a patch to refactor the zoran debugging function. This function
> > existed in all of the changed files and they also all import the
> > videocodec header file. This patch moves the dprintk function into the
> > videocodec header file and out of each of the individual files.
> >
> > -#define dprintk(num, format, args...) \
> > - do { \
> > - if (videocodec_debug >= num) \
> > - printk(format, ##args); \
> > - } while (0)
> > -
[ snip ]
>
> > +/* Print debug information based on the specified level of debugging */
> > +#define dprintk(debug, num, format, args...) \
> > +do { \
> > + if (debug > num) \
> > + printk(format, ##args); \
> > +} while (0)
> > +
>
> I don't like the new format. It needs to have a KERN_DEBUG at the
> start. Passing the param_module is awkward. No one knows what the
> magic "num" things are.
I was going to put KERN_DEBUG at the beginning, but it appears that some
of the calls already include KERN_ERR, KERN_WARNING, or KERN_INFO, but
most of them do not. Would it be better to split these into multiple
macros or use printk in those specific spots that difer?
> Using a module parameter is old school badness. The standard dev_dbg()
> macros are better and more flexible. Just use them instead.
>
> regards,
> dan carpenter
>
For using the dev_dbg() macro, do you define this in the header file
(i.e. for this it would be videocodec.h), or where should this be
included from?
---
Ian Cowan
next prev parent reply other threads:[~2022-04-21 15:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-21 0:23 [PATCH] media: staging: zoran: refactor printk debugging function Ian Cowan
2022-04-21 14:21 ` Dan Carpenter
2022-04-21 15:22 ` Ian Cowan [this message]
2022-04-21 15:52 ` Dan Carpenter
2022-04-21 18:13 ` Ian Cowan
2022-04-22 0:30 ` Ian Cowan
2022-04-22 5:10 ` Greg KH
2022-04-23 5:23 ` Ian Cowan
2022-04-23 5:51 ` Greg KH
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=YmF2mM+Lqv/HOgFl@fedora \
--to=ian@linux.cowan.aero \
--cc=clabbe@baylibre.com \
--cc=dan.carpenter@oracle.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=mchehab@kernel.org \
--cc=mjpeg-users@lists.sourceforge.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox