All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Zorro Lang <zlang@redhat.com>
Cc: David Sterba <dsterba@suse.cz>,
	Anand Jain <anand.jain@oracle.com>,
	fstests@vger.kernel.org, linux-btrfs@vger.kernel.org,
	fdmanana@kernel.org
Subject: Re: [PATCH v2 1/2] shared: move btrfs clone device testcase to the shared group
Date: Tue, 19 Mar 2024 13:43:03 -0700	[thread overview]
Message-ID: <Zfn412vXi8V7Sqd3@infradead.org> (raw)
In-Reply-To: <20240319041633.l75ifryeidjxltat@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com>

On Tue, Mar 19, 2024 at 12:16:33PM +0800, Zorro Lang wrote:
> I didn't suggest to make it a shared case directly, I asked if there's a
> _require_xxxx helper to make this case notrun on "not proper" fs, not
> just use "btrfs ext4" to be whitelist :
> 
> https://lore.kernel.org/fstests/20240312044629.hpaqdkl24nxaa3dv@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com/
> 
> In my personal opinion, the "shared" directory is a place to store the cases
> which are nearly to be generic, but not ready. It's a place to remind us
> there're still some cases use something likes "supported btrfs ext4" as the
> hard condition of _notrun, rather than a flexible _require_xxx helper. These
> cases in shared better to be moved to generic, if we can improve it in one day.
> 
> It more likes a "TODO" list of generic. If we just write it in generic/
> directory, I'm afraid we'll leave it in hundreds of generic cases then forget it.
> 
> What do you think?

I like we're you're going, but I'd like to take it a step further:

I think we should just kill _supported_fs entirely.

tests/$FSTYPE is run for $FSTYP only, period.
tests/generic/ is run for all file systems, and run/notrun deciѕions
should be based on feature checks.  Where they can't happen without
fs-sepcific infrastructure we need a _require/_have check that
switches on $FSTYP like we already have in many places.  shared
should be folded into generic.

And a list of all hte places where we have to or should plug fs
knowledge in would be really nice as well..


  parent reply	other threads:[~2024-03-19 20:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-16 17:02 [PATCH v2 0/2] fstests: new test cases for generic group Anand Jain
2024-03-16 17:02 ` [PATCH v2 1/2] shared: move btrfs clone device testcase to the shared group Anand Jain
2024-03-18 22:02   ` David Sterba
2024-03-18 22:15     ` Christoph Hellwig
2024-03-19  4:16     ` Zorro Lang
2024-03-19 17:17       ` Anand Jain
2024-03-19 17:27       ` David Sterba
2024-03-19 20:43       ` Christoph Hellwig [this message]
2024-03-20 16:08         ` David Sterba
2024-03-21 21:41           ` Christoph Hellwig
2024-04-09 14:43   ` Anand Jain
2024-03-16 17:02 ` [PATCH v2 2/2] generic: test mount fails on physical device with configured dm volume Anand Jain
2024-03-24  8:49   ` Anand Jain

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=Zfn412vXi8V7Sqd3@infradead.org \
    --to=hch@infradead.org \
    --cc=anand.jain@oracle.com \
    --cc=dsterba@suse.cz \
    --cc=fdmanana@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --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.