From: Mauro Carvalho Chehab <m.chehab@samsung.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Joe Perches <joe@perches.com>,
devel@driverdev.osuosl.org, Paul Bolle <pebolle@tiscali.nl>,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org
Subject: Re: [PATCH v2] [media] v4l: omap4iss: Add DEBUG compiler flag
Date: Thu, 06 Mar 2014 08:59:07 -0300 [thread overview]
Message-ID: <20140306085907.0e4bc30a@samsung.com> (raw)
In-Reply-To: <6116451.L9roNDfSqL@avalon>
Em Thu, 06 Mar 2014 12:00:30 +0100
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> Hi Greg,
>
> On Wednesday 05 March 2014 20:45:29 Greg Kroah-Hartman wrote:
> > On Thu, Mar 06, 2014 at 01:48:29AM +0100, Laurent Pinchart wrote:
> > > On Wednesday 05 March 2014 16:28:03 Joe Perches wrote:
> > > > On Thu, 2014-03-06 at 00:50 +0100, Laurent Pinchart wrote:
> > > > > Please note that -DDEBUG is equivalent to '#define DEBUG', not to
> > > > > '#define CONFIG_DEBUG'. 'DEBUG' needs to be defined for dev_dbg() to
> > > > > have any effect.
> > > >
> > > > Not quite. If CONFIG_DYNAMIC_DEBUG is set, these
> > > > dev_dbg statements are compiled in but not by default
> > > > set to emit output. Output can be enabled by using
> > > > dynamic_debug controls like:
> > > >
> > > > # echo -n 'file omap4iss/* +p' > <debugfs>/dynamic_debug/control
> > > >
> > > > See Documentation/dynamic-debug-howto.txt for more details.
> > >
> > > Thank you for the additional information.
> > >
> > > Would you recommend to drop driver-specific Kconfig options related to
> > > debugging and use CONFIG_DYNAMIC_DEBUG instead ?
> >
> > Yes, please do that, no one wants to rebuild drivers and subsystems with
> > different options just for debugging.
I agree that this is the best solution.
>
> Is CONFIG_DYNAMIC_DEBUG lean enough to be used on embedded systems ? Note that
> people would still have to rebuild their kernel to enable CONFIG_DYNAMIC_DEBUG
> anyway :-)
Some distros, like Fedora, ships two different kernels: one compiled with
most of those DEBUG macros disabled, and another one with them enabled:
kernel.x86_64 : The Linux kernel
kernel-debug.x86_64 : The Linux kernel compiled with extra debugging enabled
That helps to have a "production" kernel using less memory, yet allowing
one to boot with the debug Kernel, if he needs to debug some driver(s).
PS.: In Fedora, in the specific case of CONFIG_DYNAMIC_DEBUG, it has it
enabled since, at least, 2010 (when they changed the SCM to git) at the
"production" kernel even for ARM. So, I suspect that the extra amount of
memory required for it is not much, but I never actually bothered to check.
On my view, except on embedded systems with very very limited memory
constraints, it makes sense to keep CONFIG_DYNAMIC_DEBUG always enabled.
Btw, I would expect a reasonable amount of RAM on any embedded system
that supports v4l, because video buffers require a lot of memory.
Comparing to the size of those buffers, I suspect that the extra amount
of memory for the debug strings and code is negligible.
--
Cheers,
Mauro
prev parent reply other threads:[~2014-03-06 11:59 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-09 15:09 [PATCH] [media] v4l: omap4iss: Remove VIDEO_OMAP4_DEBUG Paul Bolle
2014-02-10 14:13 ` Laurent Pinchart
2014-02-10 15:13 ` Paul Bolle
2014-02-10 15:29 ` Laurent Pinchart
2014-02-11 11:17 ` [PATCH v2] [media] v4l: omap4iss: Add DEBUG compiler flag Paul Bolle
2014-02-11 12:38 ` Laurent Pinchart
2014-03-05 20:10 ` Mauro Carvalho Chehab
2014-03-05 23:50 ` Laurent Pinchart
2014-03-06 0:28 ` Joe Perches
2014-03-06 0:48 ` Laurent Pinchart
2014-03-06 1:00 ` Joe Perches
2014-03-06 1:27 ` Laurent Pinchart
2014-03-06 1:35 ` Joe Perches
2014-03-06 1:52 ` Laurent Pinchart
2014-03-06 3:25 ` Joe Perches
2014-03-06 10:55 ` Laurent Pinchart
2014-03-06 16:47 ` Joe Perches
2014-03-06 4:45 ` Greg Kroah-Hartman
2014-03-06 10:23 ` Paul Bolle
2014-03-06 11:00 ` Laurent Pinchart
2014-03-06 11:59 ` Mauro Carvalho Chehab [this message]
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=20140306085907.0e4bc30a@samsung.com \
--to=m.chehab@samsung.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=joe@perches.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=pebolle@tiscali.nl \
/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.