From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH v2] xfs: make fatal assert failures conditional in debug mode
Date: Wed, 10 May 2017 20:54:32 +1000 [thread overview]
Message-ID: <20170510105431.GK17542@dastard> (raw)
In-Reply-To: <20170509170047.GC3241@bfoster.bfoster>
On Tue, May 09, 2017 at 01:00:50PM -0400, Brian Foster wrote:
> I rarely, if ever, have a need for assert failures to bug the kernel.
I absolutely rely on it to debug problems with the system in the
state that the problem was detected.
IOWs, what works for one person does not work for everyone.
> I'd like to be able to just turn it off in my default configs (without
> disrupting the cases where it is useful).
So, as Darrick suggested, make the sysctl value kconfig selectable.
you get what you want and it's runtime selectable...
> > > As mentioned previously, we can be more granular than the current binary
> > > toggle for debug mode. E.g., we could separate diagnostic mechanisms
> > > from test coverage mechanisms and enable the latter at a higher debug
> > > level or with a separate option entirely, if desired. IOW, I don't think
> > > that's a difficult problem to solve.
> >
> > Agreed.
Please don't. It took us years to get rid of all the stale special
snowflake conditional debug code we inherited from Irix that
bitrotted and broke because nobody ever set, say, XFS_TRANS_DEBUG in
their build, let alone tried to run a kernel with it. We took what
was useful and put it under XFS_DEBUG so that it was always run, and
the XFS code has been so much better for it....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2017-05-10 10:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-05 13:31 [PATCH v2] xfs: make fatal assert failures conditional in debug mode Brian Foster
2017-05-05 17:12 ` Bill O'Donnell
2017-05-05 23:09 ` Dave Chinner
2017-05-08 12:55 ` Brian Foster
2017-05-08 23:14 ` Dave Chinner
2017-05-09 3:02 ` Eric Sandeen
2017-05-10 10:44 ` Dave Chinner
2017-05-09 13:11 ` Brian Foster
2017-05-09 15:37 ` Darrick J. Wong
2017-05-09 17:00 ` Brian Foster
2017-05-09 17:20 ` Darrick J. Wong
2017-05-09 17:47 ` Brian Foster
2017-05-09 20:56 ` Darrick J. Wong
2017-05-10 10:54 ` Dave Chinner [this message]
2017-05-10 11:44 ` Brian Foster
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=20170510105431.GK17542@dastard \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
/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