All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Tulak <jtulak@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: fstests@vger.kernel.org, Eryu Guan <eguan@redhat.com>
Subject: Re: [PATCH v3] xfstests: Fix installation for extended
Date: Fri, 1 Jul 2016 17:51:40 +0200	[thread overview]
Message-ID: <CACj3i73csDODQ2z+RO4h-82X2a+JxeoLoBVyYj6jO1tGDfW8fQ@mail.gmail.com> (raw)
In-Reply-To: <20160701011642.GV27480@dastard>

On Fri, Jul 1, 2016 at 3:16 AM, Dave Chinner <david@fromorbit.com> wrote:
> On Thu, Jun 30, 2016 at 06:06:24PM +0200, Jan Tulak wrote:
>> xfstests supports extended test names like 314-foo-bar, but installation of
>> these tests was skipped (not matching a regexp). So this patch fixes the
>> makefiles in tests/xfs/.
>>
>> This change will have to be repeated later for other directories, as adding it
>> now everywhere would cause make install to fail if no such extended name is
>> present in the dir.
>>
>> Signed-off-by: Jan Tulak <jtulak@redhat.com>
>> ---
>> UPDATE:
>> Let it be just in tests/xfs/.
>>
>> NOTE: if tested without at first merging my 400-input-valiation test, make
>> install will fail again. :-)
>
> This really should be done in a way that doesn't fail like this so
> it can simply be added to all the tests/<fs>/Makefile and then we
> can ignore the problem again.
>
> The usual way of doing this from with the makefile is to use
> wildcard rules, something like:
>
> INSTALL_FILES = $(wildcard <regex>)
>
> install: $(addsuffix -install,$(INSTALL_FILES))
>         [.....]
>
> %-install:
>         $(INSTALL) -m 664 $* $(TARGET_DIR)
>
>
> You can use multiple wildcard matches for INSTALL_FILES if you can't
> write a single regex to grab all the filesystem that need
> installing.
>
> See, for example, tests/Makefile for an example of exactly this sort
> of wildcard matching so that the makefile does not need updating
> every time we add a new tests subdirectory.
>

OK, thank you Dave. This looks reasonable and it works. However, it
spams terminal with a line for every single file installed:

../../install-sh -o root -g root -m 644 072.out /var/lib/xfstests/tests/xfs

And it is few seconds slower for every directory. I could suppress the
output it with @, but then we would be at the beginning again... So
instead, I tried it as:

INSTALL_FILES = $(wildcard <regex>)

install:
        $(INSTALL) -m 664 $(INSTALL_FILES) $(TARGET_DIR)

This is much better and it avoids the failure issue. The only issue is
that now the make output is like:

../../install-sh -o root -g root -m 755 307 043 207 107 070 105 005
238 310 118 210 201 101 010 138 243 097 160 177 081 071 061 300 200
100 054 184 195 169 196 158 209 109 108 106 060 254 293 159 299 246
024 099 174 146 213 069 278 087 046 185 157 264 235 242 135 224 253
124 083 035 142 212 042 232 223 123 132 150 023 136 168 036 044 125
173 190 ... etc.

But I think this is as good as we can get. At least, until we ran into
"getconf ARG_MAX" limit. Still, some 2097152 chars (on my Fedora)
looks safe. It would be about 100.000 files with 20-char long name in
a single directory and we run out of 3-digit IDs for tests long before
that. :-)

And by the way, I'm adding another patch to this one and making it a
set: I found another issue with the extended names around _notrun
usage.

Cheers,
Jan

-- 
Jan Tulak
jtulak@redhat.com / jan@tulak.me

      reply	other threads:[~2016-07-01 15:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-29 14:57 [PATCH] xfstests: Fix installation for extended names Jan Tulak
2016-06-30  3:38 ` Eryu Guan
2016-06-30  8:32   ` Jan Tulak
2016-06-30  8:35 ` [PATCH v2] " Jan Tulak
2016-06-30 13:33   ` Eryu Guan
2016-06-30 15:19     ` Jan Tulak
2016-06-30 15:35       ` Eryu Guan
2016-06-30 16:06 ` [PATCH v3] xfstests: Fix installation for extended Jan Tulak
2016-06-30 16:08   ` Jan Tulak
2016-06-30 16:21     ` Eryu Guan
2016-07-01  1:16   ` Dave Chinner
2016-07-01 15:51     ` Jan Tulak [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=CACj3i73csDODQ2z+RO4h-82X2a+JxeoLoBVyYj6jO1tGDfW8fQ@mail.gmail.com \
    --to=jtulak@redhat.com \
    --cc=david@fromorbit.com \
    --cc=eguan@redhat.com \
    --cc=fstests@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 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.