All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: fstests@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH] xfstests: create a test for xfs log grant head leak detection
Date: Wed, 11 Jun 2014 09:31:06 +1000	[thread overview]
Message-ID: <20140610233106.GJ9508@dastard> (raw)
In-Reply-To: <20140610111750.GA46344@bfoster.bfoster>

On Tue, Jun 10, 2014 at 07:17:50AM -0400, Brian Foster wrote:
> On Tue, Jun 10, 2014 at 11:21:49AM +1000, Dave Chinner wrote:
> > On Fri, Jun 06, 2014 at 09:14:43AM -0400, Brian Foster wrote:
> > > +# real QA test starts here
> > > +_supported_fs xfs
> > > +_supported_os Linux
> > > +
> > > +_require_scratch
> > > +_require_freeze
> > > +
> > > +if [ ! -e /sys/fs/xfs ]
> > > +then
> > > +	_notrun "no kernel support for XFS sysfs attributes"
> > > +fi
> > 
> > _requires_xfs_sysfs
> > 
> 
> I was mulling this over as I think we'll probably end up in a situation
> where a test that depends on sysfs bits will need to check for a
> specific attribute file. E.g., some new test comes along using a new
> attribute file. Checking for /sys/fs/xfs is not sufficient for that test
> once we release a version that so far only exports the log bits.
> 
> I think we could handle that by supporting a parameter to
> _requires_xfs_sysfs that specifies the sub-attribute that must exist
> (similar to what we have for xfs_io commands). We don't need that at the
> moment, but that's good enough for me to create the requires func.

Yup, passing the name and/or sub-path of the paramter set required
sounds fine to me. it would become:

_requires_xfs_sysfs log

in this case, because the presence of the /sys/fs/xfs/<dev>/log
directory would be suficinet to indicate the test should run, yes?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: fstests@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH] xfstests: create a test for xfs log grant head leak detection
Date: Wed, 11 Jun 2014 09:31:06 +1000	[thread overview]
Message-ID: <20140610233106.GJ9508@dastard> (raw)
In-Reply-To: <20140610111750.GA46344@bfoster.bfoster>

On Tue, Jun 10, 2014 at 07:17:50AM -0400, Brian Foster wrote:
> On Tue, Jun 10, 2014 at 11:21:49AM +1000, Dave Chinner wrote:
> > On Fri, Jun 06, 2014 at 09:14:43AM -0400, Brian Foster wrote:
> > > +# real QA test starts here
> > > +_supported_fs xfs
> > > +_supported_os Linux
> > > +
> > > +_require_scratch
> > > +_require_freeze
> > > +
> > > +if [ ! -e /sys/fs/xfs ]
> > > +then
> > > +	_notrun "no kernel support for XFS sysfs attributes"
> > > +fi
> > 
> > _requires_xfs_sysfs
> > 
> 
> I was mulling this over as I think we'll probably end up in a situation
> where a test that depends on sysfs bits will need to check for a
> specific attribute file. E.g., some new test comes along using a new
> attribute file. Checking for /sys/fs/xfs is not sufficient for that test
> once we release a version that so far only exports the log bits.
> 
> I think we could handle that by supporting a parameter to
> _requires_xfs_sysfs that specifies the sub-attribute that must exist
> (similar to what we have for xfs_io commands). We don't need that at the
> moment, but that's good enough for me to create the requires func.

Yup, passing the name and/or sub-path of the paramter set required
sounds fine to me. it would become:

_requires_xfs_sysfs log

in this case, because the presence of the /sys/fs/xfs/<dev>/log
directory would be suficinet to indicate the test should run, yes?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2014-06-10 23:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-06 13:14 [PATCH] xfstests: create a test for xfs log grant head leak detection Brian Foster
2014-06-06 13:14 ` Brian Foster
2014-06-10  1:21 ` Dave Chinner
2014-06-10  1:21   ` Dave Chinner
2014-06-10 11:17   ` Brian Foster
2014-06-10 11:17     ` Brian Foster
2014-06-10 23:31     ` Dave Chinner [this message]
2014-06-10 23:31       ` Dave Chinner
2014-06-11 10:56       ` Brian Foster
2014-06-11 10:56         ` 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=20140610233106.GJ9508@dastard \
    --to=david@fromorbit.com \
    --cc=bfoster@redhat.com \
    --cc=fstests@vger.kernel.org \
    --cc=xfs@oss.sgi.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.