All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Reichl <preichl@redhat.com>
To: Eryu Guan <eguan@linux.alibaba.com>
Cc: fstests@vger.kernel.org, zlang@redhat.com, guan@eryu.me,
	Eric Sandeen <sandeen@redhat.com>,
	Dave Chinner <dchinner@redhat.com>
Subject: Re: [PATCH v2 1/4] common/rc: Add _require_{chown,chmod,symlink}()
Date: Thu, 1 Apr 2021 11:47:35 +0200	[thread overview]
Message-ID: <9f6d45ca-7f96-1cfa-5e66-a355ad4e0c7a@redhat.com> (raw)
In-Reply-To: <20210401033853.GO95214@e18g06458.et15sqa>



On 4/1/21 5:38 AM, Eryu Guan wrote:
> On Wed, Mar 31, 2021 at 12:00:02AM +0200, Pavel Reichl wrote:
>> Add helper functions that ensure that test is only executed on file
>> systems that implement chown, chmod and symbolic links.
>>
>> Fixed test are: generic/{87,88,125,126,128,193,314,317,355,597,598}
>>
>> Signed-off-by: Pavel Reichl <preichl@redhat.com>
>> ---
>>  common/rc         | 27 +++++++++++++++++++++++++++
>>  tests/generic/087 |  1 +
>>  tests/generic/088 |  1 +
>>  tests/generic/125 |  1 +
>>  tests/generic/126 |  1 +
>>  tests/generic/128 |  1 +
>>  tests/generic/193 |  1 +
>>  tests/generic/314 |  1 +
>>  tests/generic/317 |  1 +
>>  tests/generic/355 |  1 +
>>  tests/generic/597 |  1 +
>>  tests/generic/598 |  1 +
>>  12 files changed, 38 insertions(+)
>>
>> diff --git a/common/rc b/common/rc
>> index 0ce3cb0d..9cdfe21c 100644
>> --- a/common/rc
>> +++ b/common/rc
>> @@ -2129,6 +2129,33 @@ _require_user()
>>      [ "$?" == "0" ] || _notrun "$qa_user cannot execute commands."
>>  }
>>  
>> +# check for a chown support
>> +#
>> +_require_chown()
>> +{
>> +	if [ "$FSTYP" = "exfat" ]; then
>> +		_notrun "chown is not supported on $FSTYP"
>> +	fi
>> +}
>> +
>> +# check for a chmod support
>> +#
>> +_require_chmod()
>> +{
>> +	if [ "$FSTYP" = "exfat" ]; then
>> +		_notrun "chmod is not supported on $FSTYP"
>> +	fi
>> +}
>> +
> 
> Does chown/chmod fail on exfat? Like the existing _require_symlink()
> implementation and many other _require rules, we try to actually do the
> action on $TEST_DIR, and check if command succeeds to see if the action
> is supported by current $FSTYP. Is it possible for exfat to do the same
> check?
> 
> We only use whitelist if it's impossible to do such check.
> 
> Thanks,
> Eryu
> 

Hi, 

it does fail. It was actually my original intention to write the _require*() so it would check if the command succeeds as you are suggesting.

However, Eric and Dave were worried that adding more _require*() through the tests would lead to further slowing test execution. This worry actually makes sense to me.

Is there a significant benefit of testing the support vs. maintaining check based on FSTYP variable? I guess doing the check saves us from the need to update the code when new file-system is added, however actually doing the check increases time of test execution (but I haven't done any measurements yet - it's just my guess).

I really don't mind doing it either way and I'm happy to change the code - I'm just trying to explain :-)

Thanks for the comment.

Have a nice day.


  reply	other threads:[~2021-04-01  9:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-30 22:00 [PATCH v2 0/4] Fix some tests that fail for exfat FS Pavel Reichl
2021-03-30 22:00 ` [PATCH v2 1/4] common/rc: Add _require_{chown,chmod,symlink}() Pavel Reichl
2021-03-31  0:25   ` Zorro Lang
2021-03-31  7:17     ` Pavel Reichl
2021-04-01  3:38   ` Eryu Guan
2021-04-01  9:47     ` Pavel Reichl [this message]
2021-04-07 16:47       ` Eric Sandeen
2021-03-30 22:00 ` [PATCH v2 2/4] common: hide permision warning from mkswap for exfat Pavel Reichl
2021-04-07 17:03   ` Eric Sandeen
2021-04-15  9:15     ` Pavel Reichl
2021-03-30 22:00 ` [PATCH v2 3/4] generic/554: hide permision warning on exfat Pavel Reichl
2021-04-01  3:40   ` Eryu Guan
2021-03-30 22:00 ` [PATCH v2 4/4] generic/003: Amend the test for exfat Pavel Reichl
2021-04-07 18:03   ` Eric Sandeen
2021-04-15  9:14     ` Pavel Reichl

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=9f6d45ca-7f96-1cfa-5e66-a355ad4e0c7a@redhat.com \
    --to=preichl@redhat.com \
    --cc=dchinner@redhat.com \
    --cc=eguan@linux.alibaba.com \
    --cc=fstests@vger.kernel.org \
    --cc=guan@eryu.me \
    --cc=sandeen@redhat.com \
    --cc=zlang@redhat.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.