All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Peter Lafreniere <peter@n8pjl.ca>,
	segher@kernel.crashing.org, anton.ivanov@cambridgegreys.com,
	ink@jurassic.park.msu.ru, jack@suse.cz,
	johannes@sipsolutions.net, linux-alpha@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-m68k@vger.kernel.org,
	linux-mips@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-um@lists.infradead.org, linux@armlinux.org.uk,
	linuxppc-dev@lists.ozlabs.org, reiserfs-devel@vger.kernel.org,
	richard.henderson@linaro.org, richard@nod.at,
	tsbogend@alpha.franken.de
Subject: Re: [PATCH 0/7] arch/*: config: Remove ReiserFS from defconfig
Date: Wed, 20 Sep 2023 18:56:59 +0200	[thread overview]
Message-ID: <20230920165659.coe7d2lydiaatoby@quack3> (raw)
In-Reply-To: <CAMuHMdXQ=xpeY3tmLXe1kgJbRtmVAn62rEhvzO+VB7GCgy4F8w@mail.gmail.com>

On Tue 19-09-23 18:02:39, Geert Uytterhoeven wrote:
> Hi Peter,
> 
> On Tue, Sep 19, 2023 at 5:58 PM Peter Lafreniere <peter@n8pjl.ca> wrote:
> >  2) Stops building an obsolete and largely-unused filesystem unnecessarily.
> >     Some hobbyist targets like m68k and alpha may prefer to keep all filesystems
> >     available until total removal, but others like arm and UML have no need for
> >     ReiserFS to be built unless specifically configured.
> 
> As UML is used a lot for testing, isn't it actually counter-productive
> to remove ReiserFS from the UML defconfig?  The less testing it
> receives, the higher the chance of introducing regressions.

The only testing I know about for reiserfs (besides build testing) is
syzbot. And regarding the people / bots doing filesystem testing I know
none of them uses UML. Rather it is x86 VMs these days where reiserfs is
disabled in the defconfig for a *long* time (many years). Also when you do
filesystem testing, you usually just test the few filesystems you care
about and for which you have all the tools installed. So frankly I don't
see a good reason to leave reiserfs enabled in defconfigs. But sure if
m68k or other arch wants to keep reiserfs in it's defconfig for some
consistency reasons, I'm fine with it. I just suspect that for most archs
this is just a historical reason.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Peter Lafreniere <peter@n8pjl.ca>,
	segher@kernel.crashing.org, anton.ivanov@cambridgegreys.com,
	ink@jurassic.park.msu.ru, jack@suse.cz,
	johannes@sipsolutions.net, linux-alpha@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-m68k@vger.kernel.org,
	linux-mips@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-um@lists.infradead.org, linux@armlinux.org.uk,
	linuxppc-dev@lists.ozlabs.org, reiserfs-devel@vger.kernel.org,
	richard.henderson@linaro.org, richard@nod.at,
	tsbogend@alpha.franken.de
Subject: Re: [PATCH 0/7] arch/*: config: Remove ReiserFS from defconfig
Date: Wed, 20 Sep 2023 18:56:59 +0200	[thread overview]
Message-ID: <20230920165659.coe7d2lydiaatoby@quack3> (raw)
In-Reply-To: <CAMuHMdXQ=xpeY3tmLXe1kgJbRtmVAn62rEhvzO+VB7GCgy4F8w@mail.gmail.com>

On Tue 19-09-23 18:02:39, Geert Uytterhoeven wrote:
> Hi Peter,
> 
> On Tue, Sep 19, 2023 at 5:58 PM Peter Lafreniere <peter@n8pjl.ca> wrote:
> >  2) Stops building an obsolete and largely-unused filesystem unnecessarily.
> >     Some hobbyist targets like m68k and alpha may prefer to keep all filesystems
> >     available until total removal, but others like arm and UML have no need for
> >     ReiserFS to be built unless specifically configured.
> 
> As UML is used a lot for testing, isn't it actually counter-productive
> to remove ReiserFS from the UML defconfig?  The less testing it
> receives, the higher the chance of introducing regressions.

The only testing I know about for reiserfs (besides build testing) is
syzbot. And regarding the people / bots doing filesystem testing I know
none of them uses UML. Rather it is x86 VMs these days where reiserfs is
disabled in the defconfig for a *long* time (many years). Also when you do
filesystem testing, you usually just test the few filesystems you care
about and for which you have all the tools installed. So frankly I don't
see a good reason to leave reiserfs enabled in defconfigs. But sure if
m68k or other arch wants to keep reiserfs in it's defconfig for some
consistency reasons, I'm fine with it. I just suspect that for most archs
this is just a historical reason.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Peter Lafreniere <peter@n8pjl.ca>,
	segher@kernel.crashing.org, anton.ivanov@cambridgegreys.com,
	ink@jurassic.park.msu.ru, jack@suse.cz,
	johannes@sipsolutions.net, linux-alpha@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-m68k@vger.kernel.org,
	linux-mips@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-um@lists.infradead.org, linux@armlinux.org.uk,
	linuxppc-dev@lists.ozlabs.org, reiserfs-devel@vger.kernel.org,
	richard.henderson@linaro.org, richard@nod.at,
	tsbogend@alpha.franken.de
Subject: Re: [PATCH 0/7] arch/*: config: Remove ReiserFS from defconfig
Date: Wed, 20 Sep 2023 18:56:59 +0200	[thread overview]
Message-ID: <20230920165659.coe7d2lydiaatoby@quack3> (raw)
In-Reply-To: <CAMuHMdXQ=xpeY3tmLXe1kgJbRtmVAn62rEhvzO+VB7GCgy4F8w@mail.gmail.com>

On Tue 19-09-23 18:02:39, Geert Uytterhoeven wrote:
> Hi Peter,
> 
> On Tue, Sep 19, 2023 at 5:58 PM Peter Lafreniere <peter@n8pjl.ca> wrote:
> >  2) Stops building an obsolete and largely-unused filesystem unnecessarily.
> >     Some hobbyist targets like m68k and alpha may prefer to keep all filesystems
> >     available until total removal, but others like arm and UML have no need for
> >     ReiserFS to be built unless specifically configured.
> 
> As UML is used a lot for testing, isn't it actually counter-productive
> to remove ReiserFS from the UML defconfig?  The less testing it
> receives, the higher the chance of introducing regressions.

The only testing I know about for reiserfs (besides build testing) is
syzbot. And regarding the people / bots doing filesystem testing I know
none of them uses UML. Rather it is x86 VMs these days where reiserfs is
disabled in the defconfig for a *long* time (many years). Also when you do
filesystem testing, you usually just test the few filesystems you care
about and for which you have all the tools installed. So frankly I don't
see a good reason to leave reiserfs enabled in defconfigs. But sure if
m68k or other arch wants to keep reiserfs in it's defconfig for some
consistency reasons, I'm fine with it. I just suspect that for most archs
this is just a historical reason.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-m68k@vger.kernel.org, tsbogend@alpha.franken.de,
	jack@suse.cz, linux-sh@vger.kernel.org,
	richard.henderson@linaro.org, linux-um@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
	richard@nod.at, ink@jurassic.park.msu.ru,
	Peter Lafreniere <peter@n8pjl.ca>,
	linux-alpha@vger.kernel.org, linux@armlinux.org.uk,
	johannes@sipsolutions.net, reiserfs-devel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org,
	anton.ivanov@cambridgegreys.com
Subject: Re: [PATCH 0/7] arch/*: config: Remove ReiserFS from defconfig
Date: Wed, 20 Sep 2023 18:56:59 +0200	[thread overview]
Message-ID: <20230920165659.coe7d2lydiaatoby@quack3> (raw)
In-Reply-To: <CAMuHMdXQ=xpeY3tmLXe1kgJbRtmVAn62rEhvzO+VB7GCgy4F8w@mail.gmail.com>

On Tue 19-09-23 18:02:39, Geert Uytterhoeven wrote:
> Hi Peter,
> 
> On Tue, Sep 19, 2023 at 5:58 PM Peter Lafreniere <peter@n8pjl.ca> wrote:
> >  2) Stops building an obsolete and largely-unused filesystem unnecessarily.
> >     Some hobbyist targets like m68k and alpha may prefer to keep all filesystems
> >     available until total removal, but others like arm and UML have no need for
> >     ReiserFS to be built unless specifically configured.
> 
> As UML is used a lot for testing, isn't it actually counter-productive
> to remove ReiserFS from the UML defconfig?  The less testing it
> receives, the higher the chance of introducing regressions.

The only testing I know about for reiserfs (besides build testing) is
syzbot. And regarding the people / bots doing filesystem testing I know
none of them uses UML. Rather it is x86 VMs these days where reiserfs is
disabled in the defconfig for a *long* time (many years). Also when you do
filesystem testing, you usually just test the few filesystems you care
about and for which you have all the tools installed. So frankly I don't
see a good reason to leave reiserfs enabled in defconfigs. But sure if
m68k or other arch wants to keep reiserfs in it's defconfig for some
consistency reasons, I'm fine with it. I just suspect that for most archs
this is just a historical reason.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Peter Lafreniere <peter@n8pjl.ca>,
	segher@kernel.crashing.org, anton.ivanov@cambridgegreys.com,
	ink@jurassic.park.msu.ru, jack@suse.cz,
	johannes@sipsolutions.net, linux-alpha@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-m68k@vger.kernel.org,
	linux-mips@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-um@lists.infradead.org, linux@armlinux.org.uk,
	linuxppc-dev@lists.ozlabs.org, reiserfs-devel@vger.kernel.org,
	richard.henderson@linaro.org, richard@nod.at,
	tsbogend@alpha.franken.de
Subject: Re: [PATCH 0/7] arch/*: config: Remove ReiserFS from defconfig
Date: Wed, 20 Sep 2023 18:56:59 +0200	[thread overview]
Message-ID: <20230920165659.coe7d2lydiaatoby@quack3> (raw)
In-Reply-To: <CAMuHMdXQ=xpeY3tmLXe1kgJbRtmVAn62rEhvzO+VB7GCgy4F8w@mail.gmail.com>

On Tue 19-09-23 18:02:39, Geert Uytterhoeven wrote:
> Hi Peter,
> 
> On Tue, Sep 19, 2023 at 5:58 PM Peter Lafreniere <peter@n8pjl.ca> wrote:
> >  2) Stops building an obsolete and largely-unused filesystem unnecessarily.
> >     Some hobbyist targets like m68k and alpha may prefer to keep all filesystems
> >     available until total removal, but others like arm and UML have no need for
> >     ReiserFS to be built unless specifically configured.
> 
> As UML is used a lot for testing, isn't it actually counter-productive
> to remove ReiserFS from the UML defconfig?  The less testing it
> receives, the higher the chance of introducing regressions.

The only testing I know about for reiserfs (besides build testing) is
syzbot. And regarding the people / bots doing filesystem testing I know
none of them uses UML. Rather it is x86 VMs these days where reiserfs is
disabled in the defconfig for a *long* time (many years). Also when you do
filesystem testing, you usually just test the few filesystems you care
about and for which you have all the tools installed. So frankly I don't
see a good reason to leave reiserfs enabled in defconfigs. But sure if
m68k or other arch wants to keep reiserfs in it's defconfig for some
consistency reasons, I'm fine with it. I just suspect that for most archs
this is just a historical reason.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2023-09-20 16:56 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-18 17:56 [PATCH 0/7] arch/*: config: Remove ReiserFS from defconfig Peter Lafreniere
2023-09-18 17:56 ` Peter Lafreniere
2023-09-18 17:56 ` Peter Lafreniere
2023-09-18 17:56 ` Peter Lafreniere
2023-09-18 17:56 ` [PATCH 1/7] arch: um: remove " Peter Lafreniere
2023-09-18 17:56   ` Peter Lafreniere
2023-09-18 17:56 ` [PATCH 2/7] arch: powerpc: " Peter Lafreniere
2023-09-18 17:56   ` Peter Lafreniere
2023-09-18 17:56 ` [PATCH 3/7] arch: sh: " Peter Lafreniere
2023-10-24 16:46   ` John Paul Adrian Glaubitz
2023-10-24 17:45     ` Peter Lafreniere
2023-09-18 17:57 ` [PATCH 4/7] arch: mips: " Peter Lafreniere
2023-09-18 17:57 ` [PATCH 5/7] arch: m68k: " Peter Lafreniere
2023-09-19  7:19   ` Geert Uytterhoeven
2023-09-19  7:19     ` Geert Uytterhoeven
2023-09-19 13:32     ` Peter Lafreniere
2023-09-19 13:32       ` Peter Lafreniere
2023-09-18 17:57 ` [PATCH 6/7] arch: arm: " Peter Lafreniere
2023-09-18 17:57   ` Peter Lafreniere
2023-09-18 17:57 ` [PATCH 7/7] arch: alpha: " Peter Lafreniere
2023-09-18 23:41 ` [PATCH 0/7] arch/*: config: Remove " Segher Boessenkool
2023-09-18 23:41   ` Segher Boessenkool
2023-09-18 23:41   ` Segher Boessenkool
2023-09-18 23:41   ` Segher Boessenkool
2023-09-19  0:00   ` Peter Lafreniere
2023-09-19  0:00     ` Peter Lafreniere
2023-09-19  0:00     ` Peter Lafreniere
2023-09-19  0:00     ` Peter Lafreniere
2023-09-19 15:16     ` Segher Boessenkool
2023-09-19 15:16       ` Segher Boessenkool
2023-09-19 15:16       ` Segher Boessenkool
2023-09-19 15:16       ` Segher Boessenkool
2023-09-19 15:58       ` Peter Lafreniere
2023-09-19 15:58         ` Peter Lafreniere
2023-09-19 15:58         ` Peter Lafreniere
2023-09-19 15:58         ` Peter Lafreniere
2023-09-19 16:02         ` Geert Uytterhoeven
2023-09-19 16:02           ` Geert Uytterhoeven
2023-09-19 16:02           ` Geert Uytterhoeven
2023-09-19 16:02           ` Geert Uytterhoeven
2023-09-19 16:02           ` Geert Uytterhoeven
2023-09-19 16:15           ` Peter Lafreniere
2023-09-19 16:15             ` Peter Lafreniere
2023-09-19 16:15             ` Peter Lafreniere
2023-09-19 16:15             ` Peter Lafreniere
2023-09-19 16:15             ` Peter Lafreniere
2023-09-20  9:30             ` Geert Uytterhoeven
2023-09-20  9:30               ` Geert Uytterhoeven
2023-09-20  9:30               ` Geert Uytterhoeven
2023-09-20  9:30               ` Geert Uytterhoeven
2023-09-20 16:56           ` Jan Kara [this message]
2023-09-20 16:56             ` Jan Kara
2023-09-20 16:56             ` Jan Kara
2023-09-20 16:56             ` Jan Kara
2023-09-20 16:56             ` Jan Kara
2023-10-15 10:04 ` (subset) " Michael Ellerman
2023-10-15 10:04   ` Michael Ellerman
2023-10-15 10:04   ` Michael Ellerman
2023-10-15 10:04   ` Michael Ellerman

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=20230920165659.coe7d2lydiaatoby@quack3 \
    --to=jack@suse.cz \
    --cc=anton.ivanov@cambridgegreys.com \
    --cc=geert@linux-m68k.org \
    --cc=ink@jurassic.park.msu.ru \
    --cc=johannes@sipsolutions.net \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-um@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=peter@n8pjl.ca \
    --cc=reiserfs-devel@vger.kernel.org \
    --cc=richard.henderson@linaro.org \
    --cc=richard@nod.at \
    --cc=segher@kernel.crashing.org \
    --cc=tsbogend@alpha.franken.de \
    /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.