From: Dave Chinner <david@fromorbit.com>
To: Eryu Guan <guaneryu@gmail.com>
Cc: Gwendal Grignou <gwendal@chromium.org>, fstests@vger.kernel.org
Subject: Re: [PATCH 1/3] generic: workaround device where glibc is not installed
Date: Thu, 29 Nov 2018 13:10:03 +1100 [thread overview]
Message-ID: <20181129021003.GJ19305@dastard> (raw)
In-Reply-To: <20181128033039.GQ3889@desktop>
On Wed, Nov 28, 2018 at 11:30:39AM +0800, Eryu Guan wrote:
> > export CONFIG_INCLUDED=true
> > diff --git a/common/rc b/common/rc
> > index be1ed68c..992cb3cc 100644
> > --- a/common/rc
> > +++ b/common/rc
> > @@ -3686,12 +3686,6 @@ _get_block_size()
> > stat -f -c %S $1
> > }
> >
> > -get_page_size()
> > -{
> > - echo $(getconf PAGE_SIZE)
> > -}
> > -
> > -
>
> But I think we could just use "$here/src/feature -s" to get page size in
> get_page_size() and "$here/src/feature -w" to get bits per long. But we
> need to add
>
> _require_test_program "feature"
IMO, that is unnecessary. `feature` is test harness infrastructure,
like common/rc and check. If the feature binary does not build then
the test harness is running on a broken platform. IOWs, we shouldn't
be requiring functionality tests for core infrastructure - if the
core infrastructure didn't build, then there's bigger problems that
need to be fixed...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2018-11-29 13:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-27 21:43 [PATCH 0/3] Adapt some tests to ChromeOS Gwendal Grignou
2018-11-27 21:43 ` [PATCH 1/3] generic: workaround device where glibc is not installed Gwendal Grignou
2018-11-28 3:30 ` Eryu Guan
2018-11-29 2:10 ` Dave Chinner [this message]
2018-11-30 6:37 ` Eryu Guan
2018-11-27 21:43 ` [PATCH 2/3] ext4: 032: fail nicely if the test partition is not big enough for the test Gwendal Grignou
2018-11-28 3:36 ` Eryu Guan
2018-11-27 21:43 ` [PATCH 3/3] generic: exclude selinux xattr form being considered Gwendal Grignou
2018-11-28 4:37 ` Eryu Guan
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=20181129021003.GJ19305@dastard \
--to=david@fromorbit.com \
--cc=fstests@vger.kernel.org \
--cc=guaneryu@gmail.com \
--cc=gwendal@chromium.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