All of lore.kernel.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: SeongJae Park <sj@kernel.org>, Yuanchu Xie <yuanchu@google.com>,
	Shuah Khan <shuah@kernel.org>, Markus Boehme <markubo@amazon.de>,
	rientjes@google.com, Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kselftest@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] selftests/damon: make selftests executable
Date: Fri, 18 Feb 2022 08:24:28 +0000	[thread overview]
Message-ID: <20220218082428.11699-1-sj@kernel.org> (raw)
In-Reply-To: <Yg9SR88j0JV/0gKJ@kroah.com>

On Fri, 18 Feb 2022 09:01:11 +0100 Greg KH <gregkh@linuxfoundation.org> wrote:

> On Fri, Feb 18, 2022 at 07:52:54AM +0000, SeongJae Park wrote:
> > Hello Yuanchu,
> > 
> > Thank you for this patch!
> > 
> > On Fri, 18 Feb 2022 00:10:17 +0000 Yuanchu Xie <yuanchu@google.com> wrote:
> > 
> > > The damon selftests do not have the executable bit on. We fix that by
> > > setting the x bits on the .sh files similar to other existing shell
> > > selftests.
> > > 
> > > Fixes: 9ab3b0c8ef62 ("selftests/damon: split test cases")
> > > Signed-off-by: Yuanchu Xie <yuanchu@google.com>
> > 
> > Reviewed-by: SeongJae Park <sj@kernel.org>
> 
> This type of change does not work outside of git, so why not just make
> the tool that calls these scripts not care about the executable bit like
> we do for other scripts?

Actually, we made kselftest receives scripts having no executable bit[1],
though it still prints warning.  I guess Yuanchu wants to remove the warning?

To remove the warning, simply making kselftest (runner.sh) stop printing the
warning message might make more sense.  Nevertheless, it's also true that
letting some scripts have executable bits while others not looks inconsistent
to me.  That's why I left the warning message there.  Should we remove the
warning from kselftest and remove executable bits from other selftest test
scripts?  Or, let the inconsistency be?  I have no real opinion here, so just
wanted to hear others' opinion if possible.

BTW, similar issue is also in Kconfig's 'shell' macro.  For example,
'runst-version.sh' on -mm tree bothered me before[2], and now
'pahole-version.sh'.  I might make change in 'scrips/Kconfig/preprocess.c'
later.

[1] https://lore.kernel.org/linux-kselftest/20210810164534.25902-1-sj38.park@gmail.com/
[2] https://lore.kernel.org/all/20220110085952.6137-1-sj@kernel.org/


Thanks,
SJ

> 
> thanks,
> 
> greg k-h

  reply	other threads:[~2022-02-18  8:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-18  0:10 [PATCH 0/2] selftests/damon: trivial fixes Yuanchu Xie
2022-02-18  0:10 ` [PATCH 1/2] selftests/damon: add damon to selftests root Makefile Yuanchu Xie
2022-02-18  7:50   ` SeongJae Park
2022-02-18  0:10 ` [PATCH 2/2] selftests/damon: make selftests executable Yuanchu Xie
2022-02-18  7:52   ` SeongJae Park
2022-02-18  8:01     ` Greg KH
2022-02-18  8:24       ` SeongJae Park [this message]
2022-02-18 22:20         ` Shuah Khan
2022-04-18 20:06           ` Yuanchu Xie
2022-04-18 20:13             ` Yuanchu Xie

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=20220218082428.11699-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=markubo@amazon.de \
    --cc=rientjes@google.com \
    --cc=shuah@kernel.org \
    --cc=yuanchu@google.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.