All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Tso" <tytso@mit.edu>
To: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>,
	"fstests@vger.kernel.org" <fstests@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"slava@dubeyko.com" <slava@dubeyko.com>
Subject: Re: Should we consider disable generic/563 for file systems that do not support cgroup2?
Date: Sun, 19 Jul 2026 12:52:50 -0400	[thread overview]
Message-ID: <alz_HixXWhKTIfRV@mit.edu> (raw)
In-Reply-To: <alzzQA9SR55FynDu@zlang-mailbox>

On Sun, Jul 19, 2026 at 11:57:04PM -0500, Zorro Lang wrote:
> Thank you for your reply. You are right. I was just listing some
> possible options, and I did not mean we must change the kernel for
> testing. Changing the kernel just for a _notrun is indeed not worth
> it. If there is no simple way to implement the _require_* function,
> we can `_exclude_fs hfs` directly :)

I wouldn't necessarily rule out changing the kernel so that file
systems can declare whether they can support cgroupv2.  The advantage
is that we wouldn't need to keep adding "_exclude_fs xxx" each time we
try to make fstets work on the simpler file systems.  It also means
that if a file system adds support for cgroupv2, we wouldn't need to
change fstests --- also, if the patch gets backported to an older
kernel (either an LTS or an enterprise distro kernel) we don't need to
try to modulate the _exclude_fs using kernel version numbers (which
isn't guaranteed to work given the backporting possibility).

This is a philosophical issue, and reasonable people could disagree on
this approach.  For my part, I created /sys/fs/ext4/features/*
precisely so that userspace (and fstests) so we can test if a
particular feature is available on a particular kernel.  Otherwise, a
test to see whether a particular feature "works" might have a false
positive if the feature is broken, and the way we test whether the
feature is present is basically what was accidentally broken with by a
regression.

Cheers,

					- Ted

  reply	other threads:[~2026-07-19 16:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-10 19:10 Should we consider disable generic/563 for file systems that do not support cgroup2? Viacheslav Dubeyko
2026-07-17 16:19 ` Zorro Lang
2026-07-17 17:42   ` Viacheslav Dubeyko
2026-07-19 14:02   ` Theodore Tso
2026-07-19 15:57     ` Zorro Lang
2026-07-19 16:52       ` Theodore Tso [this message]
2026-07-19 19:15         ` Zorro Lang
2026-07-20  8:07           ` Christoph Hellwig

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=alz_HixXWhKTIfRV@mit.edu \
    --to=tytso@mit.edu \
    --cc=Slava.Dubeyko@ibm.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=slava@dubeyko.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.