Message ID | 20230918175529.19011-1-peter@n8pjl.ca |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp3008767vqi; Mon, 18 Sep 2023 16:06:49 -0700 (PDT) X-Google-Smtp-Source: AGHT+IESc4y303Bdmqs/zDahk+4S2ezEm/QV9HXAZbT1rEUdQQtEljtdxTZLLR73aRuTtvmG2iQi X-Received: by 2002:a05:6830:614:b0:6b7:4a86:f038 with SMTP id w20-20020a056830061400b006b74a86f038mr10889188oti.15.1695078409015; Mon, 18 Sep 2023 16:06:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695078408; cv=none; d=google.com; s=arc-20160816; b=gk41nLTwycVGLE8/sE4XBvQ6uZ6FytIyNVJOK2mL8msBYMX8+1+VhKv5wYQAsBcsCY YPSJViGq0FJKkEJUMcfcuM+VErKymX26FLUndnTTRnmdWUrewlWiM70DFBSlBZC5fkeo RkZI0+nqb/9hX9m++zCBFTv9322pY8mnd/UoxDhlknCAMGVXfU2k1YNJmMloRwxd8Avo b66CWBc2h0myjLDFzNpxeWPalJt8ipCAUteSomuDDjfdnGz6h/CUY814QkkETdGj/H52 +S+nPSB2zKncXJmcheaZLXRD1+Xn/M0i1Xf606RZRSK/YNxLyentYzh1dtZT8lsNfmY7 JF1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :feedback-id:message-id:subject:cc:from:to:date:dkim-signature; bh=KDmGL0149HMvYz0D68P8rK9iJncYI66ZFd51OEaftAc=; fh=As1rtGnl2dXR/dVg6Uau/s/c19pFFZMeh0UnSvRlCJs=; b=PtkxqrOpl7fB0eMJeF7VVtFb4OMZWxLNV37F2FgWnWjydgiiw0TboEQApIT4qSK0/0 nrrwxTyKRu9hBkxGahadojocLEvKiSmnBCF2+oS3+NtCX4ulkpTe6RgpA81p7v4iA+ZC JCNgJk2vhr3VfI6HLW2/AwnIQhDLbwdwvIadJavmN1wbk6k3Jntp/OJnbFblqJq2Uyc1 0XIsDVasMplNWTroe77o8SapjVBg3dGquc7a5qcjlyQs3EpY9rL3gl4Z0kzBhQrhRKsL 1/ADDyoQ59Vmb0N9xP9G5wOP/1I2bcTOCMrvGasmyB3W0TRersuzzJoAUBEUEw3eRuzJ MPug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@n8pjl.ca header.s=protonmail2 header.b=XDyAGqfx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=n8pjl.ca Received: from pete.vger.email (pete.vger.email. [23.128.96.36]) by mx.google.com with ESMTPS id x14-20020a65538e000000b00566058702e8si8614305pgq.236.2023.09.18.16.06.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Sep 2023 16:06:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36; Authentication-Results: mx.google.com; dkim=pass header.i=@n8pjl.ca header.s=protonmail2 header.b=XDyAGqfx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=n8pjl.ca Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id 2C86F807FD42; Mon, 18 Sep 2023 10:56:43 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229795AbjIRR4a (ORCPT <rfc822;kernel.ruili@gmail.com> + 25 others); Mon, 18 Sep 2023 13:56:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229454AbjIRR43 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 18 Sep 2023 13:56:29 -0400 Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 684ABDB; Mon, 18 Sep 2023 10:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=n8pjl.ca; s=protonmail2; t=1695059779; x=1695318979; bh=KDmGL0149HMvYz0D68P8rK9iJncYI66ZFd51OEaftAc=; h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=XDyAGqfxs1IhZyrSbs3kXmWVIDtAAGsbXg/jRzsX7fuS5Oxw4QNBzYWsvFGPZ+ksw S5Zcze4DfsU+j4F71vMZOBVGe3BZKYabMh1wfnbZ2ABquD3iq/MryJ0VB04GGHqRW3 gnQBHdLwQI3E7N3+pV5UgFQGhEjTazGFHroCb4KlhwP9A18gG508T7Pqs5jbffIgxO cUkXsv81IXGY6O6u6TWRNYFNwN9rAhwcn1b7zAnxuUbHTSaeD2idJu0SKxFygNCYtF S9e7CJc5qlz+kEo5lV3WyEyT1tOTgZkgAyKcyZB3b18aHv/xFJwzM9+FJT8sFeXCTe SfZ1idLrRGTVw== Date: Mon, 18 Sep 2023 17:56:09 +0000 To: reiserfs-devel@vger.kernel.org From: Peter Lafreniere <peter@n8pjl.ca> Cc: Peter Lafreniere <peter@n8pjl.ca>, jack@suse.cz, linux-kernel@vger.kernel.org, richard@nod.at, anton.ivanov@cambridgegreys.com, johannes@sipsolutions.net, linuxppc-dev@lists.ozlabs.org, linux-um@lists.infradead.org, linux-sh@vger.kernel.org, tsbogend@alpha.franken.de, linux-mips@vger.kernel.org, linux-m68k@lists.linux-m68k.org, geert@linux-m68k.org, linux-arm-kernel@lists.infradead.org, linux@armlinux.org.uk, linux-alpha@vger.kernel.org, richard.henderson@linaro.org, ink@jurassic.park.msu.ru Subject: [PATCH 0/7] arch/*: config: Remove ReiserFS from defconfig Message-ID: <20230918175529.19011-1-peter@n8pjl.ca> Feedback-ID: 53133685:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Mon, 18 Sep 2023 10:56:43 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777418537750457345 X-GMAIL-MSGID: 1777418537750457345 |
Series |
arch/*: config: Remove ReiserFS from defconfig
|
|
Message
Peter Lafreniere
Sept. 18, 2023, 5:56 p.m. UTC
ReiserFS has been considered deprecated for 19 months since commit eb103a51640e ("reiserfs: Deprecate reiserfs"). However, there are several architectures that still build it into their defconfig kernels. As ReiserFS will be removed in 2025, delete all ReiserFS-related options from defconfig files before the filesystem's removal. The series is intended to be approved/rejected on an arch-by-arch basis. No patch is dependant upon another in the series. See discussion originating in, Link: https://lore.kernel.org/linux-um/20230918125744.4342-1-peter@n8pjl.ca/ Peter Lafreniere (7): arch: um: remove ReiserFS from defconfig arch: powerpc: remove ReiserFS from defconfig arch: sh: remove ReiserFS from defconfig arch: mips: remove ReiserFS from defconfig arch: m68k: remove ReiserFS from defconfig arch: arm: remove ReiserFS from defconfig arch: alpha: remove ReiserFS from defconfig arch/alpha/configs/defconfig | 1 - arch/arm/configs/pxa_defconfig | 4 ---- arch/m68k/configs/amiga_defconfig | 1 - arch/m68k/configs/apollo_defconfig | 1 - arch/m68k/configs/atari_defconfig | 1 - arch/m68k/configs/bvme6000_defconfig | 1 - arch/m68k/configs/hp300_defconfig | 1 - arch/m68k/configs/mac_defconfig | 1 - arch/m68k/configs/multi_defconfig | 1 - arch/m68k/configs/mvme147_defconfig | 1 - arch/m68k/configs/mvme16x_defconfig | 1 - arch/m68k/configs/q40_defconfig | 1 - arch/m68k/configs/sun3_defconfig | 1 - arch/m68k/configs/sun3x_defconfig | 1 - arch/mips/configs/fuloong2e_defconfig | 1 - arch/mips/configs/jazz_defconfig | 4 ---- arch/mips/configs/lemote2f_defconfig | 3 --- arch/mips/configs/malta_defconfig | 5 ----- arch/mips/configs/malta_kvm_defconfig | 5 ----- arch/mips/configs/maltaup_xpa_defconfig | 5 ----- arch/mips/configs/rm200_defconfig | 4 ---- arch/powerpc/configs/44x/sam440ep_defconfig | 1 - arch/powerpc/configs/g5_defconfig | 4 ---- arch/powerpc/configs/ppc64e_defconfig | 4 ---- arch/powerpc/configs/ppc6xx_defconfig | 5 ----- arch/sh/configs/landisk_defconfig | 1 - arch/sh/configs/titan_defconfig | 1 - arch/um/configs/i386_defconfig | 1 - arch/um/configs/x86_64_defconfig | 1 - 29 files changed, 62 deletions(-)
Comments
On Mon, Sep 18, 2023 at 05:56:09PM +0000, Peter Lafreniere wrote: > ReiserFS has been considered deprecated for 19 months since commit > eb103a51640e ("reiserfs: Deprecate reiserfs"). However, there are > several architectures that still build it into their defconfig kernels. > > As ReiserFS will be removed in 2025, delete all ReiserFS-related options > from defconfig files before the filesystem's removal. This is essentially equivalent to deleting the filesystem now. Why do this? Is there such a hurry? Segher
On Monday, September 18th, 2023 at 19:41, Segher Boessenkool <segher@kernel.crashing.org> wrote: > On Mon, Sep 18, 2023 at 05:56:09PM +0000, Peter Lafreniere wrote: > > > ReiserFS has been considered deprecated for 19 months since commit > > eb103a51640e ("reiserfs: Deprecate reiserfs"). However, there are > > several architectures that still build it into their defconfig kernels. > > > > As ReiserFS will be removed in 2025, delete all ReiserFS-related options > > from defconfig files before the filesystem's removal. > > > This is essentially equivalent to deleting the filesystem now. Why do > this? Is there such a hurry? This is not equivalent to deleting the filesystem. The filesystem can still be configured into kernels, and few distros use a defconfig kernel anyway. > > > Segher Cheers, Peter Lafreniere <peter@n8pjl.ca>
On Tue, Sep 19, 2023 at 12:00:34AM +0000, Peter Lafreniere wrote: > On Monday, September 18th, 2023 at 19:41, Segher Boessenkool <segher@kernel.crashing.org> wrote: > > On Mon, Sep 18, 2023 at 05:56:09PM +0000, Peter Lafreniere wrote: > > > > > ReiserFS has been considered deprecated for 19 months since commit > > > eb103a51640e ("reiserfs: Deprecate reiserfs"). However, there are > > > several architectures that still build it into their defconfig kernels. > > > > > > As ReiserFS will be removed in 2025, delete all ReiserFS-related options > > > from defconfig files before the filesystem's removal. > > > > > > This is essentially equivalent to deleting the filesystem now. Why do > > this? Is there such a hurry? > > This is not equivalent to deleting the filesystem. The filesystem can still > be configured into kernels, and few distros use a defconfig kernel anyway. Most people who compile kernels use defconfigs though. Distros are a tiny minority if you look at builds. Again: why do you want this? Segher
On Tue, Sep 19, 2023 at 11:16, Segher Boessenkool wrote: > > On Tue, Sep 19, 2023 at 12:00:34AM +0000, Peter Lafreniere wrote: > > > On Monday, September 18th, 2023 at 19:41, Segher Boessenkool segher@kernel.crashing.org wrote: > > > > > On Mon, Sep 18, 2023 at 05:56:09PM +0000, Peter Lafreniere wrote: > > > > > > > ReiserFS has been considered deprecated for 19 months since commit > > > > eb103a51640e ("reiserfs: Deprecate reiserfs"). However, there are > > > > several architectures that still build it into their defconfig kernels. > > > > > > > > As ReiserFS will be removed in 2025, delete all ReiserFS-related options > > > > from defconfig files before the filesystem's removal. > > > > > > This is essentially equivalent to deleting the filesystem now. Why do > > > this? Is there such a hurry? > > > > This is not equivalent to deleting the filesystem. The filesystem can still > > be configured into kernels, and few distros use a defconfig kernel anyway. > > > Most people who compile kernels use defconfigs though. Distros are a > tiny minority if you look at builds. > > Again: why do you want this? > Because the filesystem is deprecated and rarely used. Those who do use ReiserFS should migrate away from it or get ready to stop upgrading their kernels soon. This removal from defconfig: 1) Serves as a reminder to those that use the fs that they should take the above actions, but with the filesystem staying available should they need it. 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. 3) Arguably simplifies the removal of the filesystem when that takes place. This point is admittedly quite weak. 4) Has to happen someday, unless someone steps up and volunteers to maintain the fs. I don't find it worthwhile, but you can if you'd like. Perhaps work towards removal will cause a user to step forward and keep their beloved filesystem around? 5) Doesn't actually remove support for the filesystem whatsoever. I can't emphasize this enough: users who build their own kernel and maintain a niche filesystem like ReiserFS should know how to flip a Kconfig switch. > > Segher Cheers, Peter
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. Gr{oetje,eeting}s, Geert
Hi Geert, On Tue, Sep 19, 2023 at 12:02, Geert Uytterhoeven <geert@linux-m68k.org> 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. UML is used for testing, but in my view that makes the inclusion of ReiserFS in its defconfig even worse. Users of UML are trying to test a particular function, and so tend to use ext[2-4], as those are included in the defconfig and are well tested and stable. So there is no extra testing being done on ReiserFS due to its inclusion in the defconfig. Keeping UML's defconfig as slim as possible improves build times, which is particularly important for kernel testing and development. > > Gr{oetje,eeting}s, > > Geert > Cheers, Peter Lafreniere
Hi Peter, On Tue, Sep 19, 2023 at 6:16 PM Peter Lafreniere <peter@n8pjl.ca> wrote: > On Tue, Sep 19, 2023 at 12:02, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > 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. > > UML is used for testing, but in my view that makes the inclusion of > ReiserFS in its defconfig even worse. Users of UML are trying to test a Why? Because you want to avoid doing any testing at all on deprecated features? > particular function, and so tend to use ext[2-4], as those are included in > the defconfig and are well tested and stable. So there is no extra testing > being done on ReiserFS due to its inclusion in the defconfig. I'd expect global file system testers to use something along the line of: for i in $(grep -v nodev /proc/filesystems ); do echo --- Testing $i --- dd if=/dev/zero of=testimage bs=1M count=1 seek=10000 mkfs.$i testimage mount testimage /mnt -t $i [run xfstests on testimage] rm -f testimage done > Keeping UML's defconfig as slim as possible improves build times, which is > particularly important for kernel testing and development. Good luck testing all functionality using a "slim" kernel ;-) Gr{oetje,eeting}s, Geert
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
On Mon, 18 Sep 2023 17:56:09 +0000, Peter Lafreniere wrote: > ReiserFS has been considered deprecated for 19 months since commit > eb103a51640e ("reiserfs: Deprecate reiserfs"). However, there are > several architectures that still build it into their defconfig kernels. > > As ReiserFS will be removed in 2025, delete all ReiserFS-related options > from defconfig files before the filesystem's removal. > > [...] Applied to powerpc/next. [2/7] arch: powerpc: remove ReiserFS from defconfig https://git.kernel.org/powerpc/c/c945e6f453a361b0e9daddd2be9c099d1b80d6f8 cheers