Message ID | 20230918175529.19011-1-peter@n8pjl.ca (mailing list archive) |
---|---|
Headers | show |
Series | arch/*: config: Remove ReiserFS from defconfig | expand |
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