| Message ID | 20250415-orchester-robben-2be52e119ee4@brauner (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | hfs{plus}: add deprecation warning | expand |
On Tue 15-04-25 09:51:37, Christian Brauner wrote: > Both the hfs and hfsplus filesystem have been orphaned since at least > 2014, i.e., over 10 years. It's time to remove them from the kernel as > they're exhibiting more and more issues and no one is stepping up to > fixing them. > > Signed-off-by: Christian Brauner <brauner@kernel.org> Looks good. And I agree hopefully it sparks interest in the maintainership because this is not completely useless filesystem: Acked-by: Jan Kara <jack@suse.cz> Honza > --- > fs/hfs/super.c | 2 ++ > fs/hfsplus/super.c | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/fs/hfs/super.c b/fs/hfs/super.c > index fe09c2093a93..4413cd8feb9e 100644 > --- a/fs/hfs/super.c > +++ b/fs/hfs/super.c > @@ -404,6 +404,8 @@ static int hfs_init_fs_context(struct fs_context *fc) > { > struct hfs_sb_info *hsb; > > + pr_warn("The hfs filesystem is deprecated and scheduled to be removed from the kernel in 2025\n"); > + > hsb = kzalloc(sizeof(struct hfs_sb_info), GFP_KERNEL); > if (!hsb) > return -ENOMEM; > diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c > index 948b8aaee33e..58cff4b2a3b4 100644 > --- a/fs/hfsplus/super.c > +++ b/fs/hfsplus/super.c > @@ -656,6 +656,8 @@ static int hfsplus_init_fs_context(struct fs_context *fc) > { > struct hfsplus_sb_info *sbi; > > + pr_warn("The hfsplus filesystem is deprecated and scheduled to be removed from the kernel in 2025\n"); > + > sbi = kzalloc(sizeof(struct hfsplus_sb_info), GFP_KERNEL); > if (!sbi) > return -ENOMEM; > -- > 2.47.2 >
On Tue, Apr 15, 2025 at 09:51:37AM +0200, Christian Brauner wrote: > Both the hfs and hfsplus filesystem have been orphaned since at least > 2014, i.e., over 10 years. It's time to remove them from the kernel as > they're exhibiting more and more issues and no one is stepping up to > fixing them. > > Signed-off-by: Christian Brauner <brauner@kernel.org> > --- > fs/hfs/super.c | 2 ++ > fs/hfsplus/super.c | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/fs/hfs/super.c b/fs/hfs/super.c > index fe09c2093a93..4413cd8feb9e 100644 > --- a/fs/hfs/super.c > +++ b/fs/hfs/super.c > @@ -404,6 +404,8 @@ static int hfs_init_fs_context(struct fs_context *fc) > { > struct hfs_sb_info *hsb; > > + pr_warn("The hfs filesystem is deprecated and scheduled to be removed from the kernel in 2025\n"); Does this mean before or after the 2025 LTS kernel is released? I would say that we ought to let this circulate more widely among users, but OTOH I guess no maintainer for a decade is really bad. --D > + > hsb = kzalloc(sizeof(struct hfs_sb_info), GFP_KERNEL); > if (!hsb) > return -ENOMEM; > diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c > index 948b8aaee33e..58cff4b2a3b4 100644 > --- a/fs/hfsplus/super.c > +++ b/fs/hfsplus/super.c > @@ -656,6 +656,8 @@ static int hfsplus_init_fs_context(struct fs_context *fc) > { > struct hfsplus_sb_info *sbi; > > + pr_warn("The hfsplus filesystem is deprecated and scheduled to be removed from the kernel in 2025\n"); > + > sbi = kzalloc(sizeof(struct hfsplus_sb_info), GFP_KERNEL); > if (!sbi) > return -ENOMEM; > -- > 2.47.2 > >
On Tue, Apr 15, 2025 at 07:49:07AM -0700, Darrick J. Wong wrote: > On Tue, Apr 15, 2025 at 09:51:37AM +0200, Christian Brauner wrote: > > Both the hfs and hfsplus filesystem have been orphaned since at least > > 2014, i.e., over 10 years. It's time to remove them from the kernel as > > they're exhibiting more and more issues and no one is stepping up to > > fixing them. > > > > Signed-off-by: Christian Brauner <brauner@kernel.org> > > --- > > fs/hfs/super.c | 2 ++ > > fs/hfsplus/super.c | 2 ++ > > 2 files changed, 4 insertions(+) > > > > diff --git a/fs/hfs/super.c b/fs/hfs/super.c > > index fe09c2093a93..4413cd8feb9e 100644 > > --- a/fs/hfs/super.c > > +++ b/fs/hfs/super.c > > @@ -404,6 +404,8 @@ static int hfs_init_fs_context(struct fs_context *fc) > > { > > struct hfs_sb_info *hsb; > > > > + pr_warn("The hfs filesystem is deprecated and scheduled to be removed from the kernel in 2025\n"); > > Does this mean before or after the 2025 LTS kernel is released? I would I would've tried before the LTS release... > say that we ought to let this circulate more widely among users, but which is a valid point. The removal of reiserfs and sysv has been pretty surgically clean. So at least from my POV it should be simple enough to revert the removal. But I'm not dealing with stable kernels so I have no intuition about the pain involved. > OTOH I guess no maintainer for a decade is really bad. > > --D > > > + > > hsb = kzalloc(sizeof(struct hfs_sb_info), GFP_KERNEL); > > if (!hsb) > > return -ENOMEM; > > diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c > > index 948b8aaee33e..58cff4b2a3b4 100644 > > --- a/fs/hfsplus/super.c > > +++ b/fs/hfsplus/super.c > > @@ -656,6 +656,8 @@ static int hfsplus_init_fs_context(struct fs_context *fc) > > { > > struct hfsplus_sb_info *sbi; > > > > + pr_warn("The hfsplus filesystem is deprecated and scheduled to be removed from the kernel in 2025\n"); > > + > > sbi = kzalloc(sizeof(struct hfsplus_sb_info), GFP_KERNEL); > > if (!sbi) > > return -ENOMEM; > > -- > > 2.47.2 > > > >
On Wed, Apr 16, 2025 at 08:27:19AM +0200, Christian Brauner wrote: > On Tue, Apr 15, 2025 at 07:49:07AM -0700, Darrick J. Wong wrote: > > On Tue, Apr 15, 2025 at 09:51:37AM +0200, Christian Brauner wrote: > > > Both the hfs and hfsplus filesystem have been orphaned since at least > > > 2014, i.e., over 10 years. It's time to remove them from the kernel as > > > they're exhibiting more and more issues and no one is stepping up to > > > fixing them. > > > > > > Signed-off-by: Christian Brauner <brauner@kernel.org> > > > --- > > > fs/hfs/super.c | 2 ++ > > > fs/hfsplus/super.c | 2 ++ > > > 2 files changed, 4 insertions(+) > > > > > > diff --git a/fs/hfs/super.c b/fs/hfs/super.c > > > index fe09c2093a93..4413cd8feb9e 100644 > > > --- a/fs/hfs/super.c > > > +++ b/fs/hfs/super.c > > > @@ -404,6 +404,8 @@ static int hfs_init_fs_context(struct fs_context *fc) > > > { > > > struct hfs_sb_info *hsb; > > > > > > + pr_warn("The hfs filesystem is deprecated and scheduled to be removed from the kernel in 2025\n"); > > > > Does this mean before or after the 2025 LTS kernel is released? I would > > I would've tried before the LTS release... Well you still could. No better way to get an oft-ignored filesystem back into maintenance by throwing down a deprecation notice. :) > > say that we ought to let this circulate more widely among users, but > > which is a valid point. The removal of reiserfs and sysv has been pretty > surgically clean. So at least from my POV it should be simple enough to > revert the removal. But I'm not dealing with stable kernels so I have no > intuition about the pain involved. It'll probably cause a lot of pain for the distributions that support PPC Macs because that's the only fs that the OF knows how to read for bootfiles. For dual-boot Intel Macs, their EFI partition is usually HFS+ and contains various system files (+ grub), but their EFI actually can read FAT. I have an old 2012 Mac Mini that runs exclusively Debian, and a FAT32 ESP works just fine. > > OTOH I guess no maintainer for a decade is really bad. On those grounds, Acked-by: "Darrick J. Wong" <djwong@kernel.org> --D > > > > --D > > > > > + > > > hsb = kzalloc(sizeof(struct hfs_sb_info), GFP_KERNEL); > > > if (!hsb) > > > return -ENOMEM; > > > diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c > > > index 948b8aaee33e..58cff4b2a3b4 100644 > > > --- a/fs/hfsplus/super.c > > > +++ b/fs/hfsplus/super.c > > > @@ -656,6 +656,8 @@ static int hfsplus_init_fs_context(struct fs_context *fc) > > > { > > > struct hfsplus_sb_info *sbi; > > > > > > + pr_warn("The hfsplus filesystem is deprecated and scheduled to be removed from the kernel in 2025\n"); > > > + > > > sbi = kzalloc(sizeof(struct hfsplus_sb_info), GFP_KERNEL); > > > if (!sbi) > > > return -ENOMEM; > > > -- > > > 2.47.2 > > > > > >
On Wed, 2025-04-16 at 08:06 -0700, Darrick J. Wong wrote: > On Wed, Apr 16, 2025 at 08:27:19AM +0200, Christian Brauner wrote: > > On Tue, Apr 15, 2025 at 07:49:07AM -0700, Darrick J. Wong wrote: > > > On Tue, Apr 15, 2025 at 09:51:37AM +0200, Christian Brauner wrote: > > > > Both the hfs and hfsplus filesystem have been orphaned since at least > > > > 2014, i.e., over 10 years. It's time to remove them from the kernel as > > > > they're exhibiting more and more issues and no one is stepping up to > > > > fixing them. > > > > > > > > Signed-off-by: Christian Brauner <brauner@kernel.org> > > > > --- > > > > fs/hfs/super.c | 2 ++ > > > > fs/hfsplus/super.c | 2 ++ > > > > 2 files changed, 4 insertions(+) > > > > > > > > diff --git a/fs/hfs/super.c b/fs/hfs/super.c > > > > index fe09c2093a93..4413cd8feb9e 100644 > > > > --- a/fs/hfs/super.c > > > > +++ b/fs/hfs/super.c > > > > @@ -404,6 +404,8 @@ static int hfs_init_fs_context(struct fs_context *fc) > > > > { > > > > struct hfs_sb_info *hsb; > > > > > > > > + pr_warn("The hfs filesystem is deprecated and scheduled to be removed from the kernel in 2025\n"); > > > > > > Does this mean before or after the 2025 LTS kernel is released? I would > > > > I would've tried before the LTS release... > > Well you still could. No better way to get an oft-ignored filesystem > back into maintenance by throwing down a deprecation notice. :) > > > > say that we ought to let this circulate more widely among users, but > > > > which is a valid point. The removal of reiserfs and sysv has been pretty > > surgically clean. So at least from my POV it should be simple enough to > > revert the removal. But I'm not dealing with stable kernels so I have no > > intuition about the pain involved. > > It'll probably cause a lot of pain for the distributions that support > PPC Macs because that's the only fs that the OF knows how to read for > bootfiles. For dual-boot Intel Macs, their EFI partition is usually > HFS+ and contains various system files (+ grub), but their EFI actually > can read FAT. I have an old 2012 Mac Mini that runs exclusively Debian, > and a FAT32 ESP works just fine. > > > > OTOH I guess no maintainer for a decade is really bad. > > On those grounds, > Acked-by: "Darrick J. Wong" <djwong@kernel.org> > > --D > > > > > > > --D > > > > > > > + > > > > hsb = kzalloc(sizeof(struct hfs_sb_info), GFP_KERNEL); > > > > if (!hsb) > > > > return -ENOMEM; > > > > diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c > > > > index 948b8aaee33e..58cff4b2a3b4 100644 > > > > --- a/fs/hfsplus/super.c > > > > +++ b/fs/hfsplus/super.c > > > > @@ -656,6 +656,8 @@ static int hfsplus_init_fs_context(struct fs_context *fc) > > > > { > > > > struct hfsplus_sb_info *sbi; > > > > > > > > + pr_warn("The hfsplus filesystem is deprecated and scheduled to be removed from the kernel in 2025\n"); > > > > + > > > > sbi = kzalloc(sizeof(struct hfsplus_sb_info), GFP_KERNEL); > > > > if (!sbi) > > > > return -ENOMEM; > > > > -- > > > > 2.47.2 > > > > > > > > > I contributed to HFS+ file system driver more than 10 years ago. And I was completely discouraged because nobody maintained the HFS+ code base. But I would prefer to see the HFS+ in kernel tree instead of complete removal. As far as I can see, we are still receiving some patches for HFS/HFS+ code base. Nowadays, I am mostly busy with CephFS and SSDFS file systems. But if we need more systematic activity on HFS/HFS+, then I can find some time for HFS/HFS+ testing, bug fix, and pathes review. I am not sure that I would have enough time for HFS+ active development. But is it really that nobody would like to be the maintainer of HFS/HFS+? Have we asked the contributors and reviewers of HFS/HFS+? Thanks, Slava.
Hello Christian, On Tue, 2025-04-15 at 09:51 +0200, Christian Brauner wrote: > Both the hfs and hfsplus filesystem have been orphaned since at least > 2014, i.e., over 10 years. It's time to remove them from the kernel as > they're exhibiting more and more issues and no one is stepping up to > fixing them. I might be willing to take over maintainership as we definitely need this driver to stay for Debian Ports as otherwise we won't be able to boot PowerMacs using GRUB. Developers on the grub-devel mailing list might be interested in this discussion as well as GRUB won't be usable anymore on PowerMacs with HFS/HFS+ being removed from the kernel. Adrian
Hello Viacheslav, On Wed, 2025-04-16 at 17:56 +0000, Viacheslav Dubeyko wrote: > I contributed to HFS+ file system driver more than 10 years ago. And I was > completely discouraged because nobody maintained the HFS+ code base. But I would > prefer to see the HFS+ in kernel tree instead of complete removal. As far as I > can see, we are still receiving some patches for HFS/HFS+ code base. Nowadays, I > am mostly busy with CephFS and SSDFS file systems. But if we need more > systematic activity on HFS/HFS+, then I can find some time for HFS/HFS+ testing, > bug fix, and pathes review. I am not sure that I would have enough time for HFS+ > active development. But is it really that nobody would like to be the maintainer > of HFS/HFS+? Have we asked the contributors and reviewers of HFS/HFS+? If you're willing to step up as a maintainer, I would be happy to assist you by testing and reviewing patches. I have PowerMacs available for testing and it's also possible to just install Debian's 32-bit and 64-bit PowerPC on an emulated PowerMac on QEMU using the "mac99" machine types to test booting from an HFS/HFS+ partition [1]. I am Debian's primary maintainer of these PowerPC ports in Debian (not to be confused with the little-endian PowerPC port) and I can also easily build various test images if needed. Please let me know if you're interested in working together on the HFS/HFS+ driver. Adrian > [1] https://cdimage.debian.org/cdimage/ports/snapshots/2025-04-01/
Hi Adrian, On Thu, 2025-04-17 at 11:29 +0200, John Paul Adrian Glaubitz wrote: > Hello Viacheslav, > > On Wed, 2025-04-16 at 17:56 +0000, Viacheslav Dubeyko wrote: > > I contributed to HFS+ file system driver more than 10 years ago. And I was > > completely discouraged because nobody maintained the HFS+ code base. But I would > > prefer to see the HFS+ in kernel tree instead of complete removal. As far as I > > can see, we are still receiving some patches for HFS/HFS+ code base. Nowadays, I > > am mostly busy with CephFS and SSDFS file systems. But if we need more > > systematic activity on HFS/HFS+, then I can find some time for HFS/HFS+ testing, > > bug fix, and pathes review. I am not sure that I would have enough time for HFS+ > > active development. But is it really that nobody would like to be the maintainer > > of HFS/HFS+? Have we asked the contributors and reviewers of HFS/HFS+? > > If you're willing to step up as a maintainer, I would be happy to assist you by > testing and reviewing patches. I have PowerMacs available for testing and it's > also possible to just install Debian's 32-bit and 64-bit PowerPC on an emulated > PowerMac on QEMU using the "mac99" machine types to test booting from an HFS/HFS+ > partition [1]. > > I am Debian's primary maintainer of these PowerPC ports in Debian (not to be confused > with the little-endian PowerPC port) and I can also easily build various test images > if needed. > > Please let me know if you're interested in working together on the HFS/HFS+ driver. > Sounds good! Yes, I am interested in working together on the HFS/HFS+ driver. :) And, yes, I can consider to be the maintainer of HFS/HFS+ driver. We can maintain the HFS/HFS+ driver together because two maintainers are better than one. Especially, if there is the practical need of having HFS/HFS+ driver in Linux kernel. Thanks, Slava.
Hi Slava, On Thu, 2025-04-17 at 18:10 +0000, Viacheslav Dubeyko wrote: > Sounds good! Yes, I am interested in working together on the HFS/HFS+ driver. :) > And, yes, I can consider to be the maintainer of HFS/HFS+ driver. We can > maintain the HFS/HFS+ driver together because two maintainers are better than > one. Especially, if there is the practical need of having HFS/HFS+ driver in > Linux kernel. OK, then let's do this together! While I'm already a kernel maintainer (for arch/sh), I wouldn't call myself an expert on filesystems and I feel way more comfortable working on this when there is a second person around with experience with hacking on filesystems. Can you send a patch to update MAINTAINERS? My mail entry would be: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Adrian
Hi Adrian, On Thu, 2025-04-17 at 20:14 +0200, John Paul Adrian Glaubitz wrote: > Hi Slava, > > On Thu, 2025-04-17 at 18:10 +0000, Viacheslav Dubeyko wrote: > > Sounds good! Yes, I am interested in working together on the HFS/HFS+ driver. :) > > And, yes, I can consider to be the maintainer of HFS/HFS+ driver. We can > > maintain the HFS/HFS+ driver together because two maintainers are better than > > one. Especially, if there is the practical need of having HFS/HFS+ driver in > > Linux kernel. > > OK, then let's do this together! While I'm already a kernel maintainer (for arch/sh), > I wouldn't call myself an expert on filesystems and I feel way more comfortable working > on this when there is a second person around with experience with hacking on filesystems. > > Can you send a patch to update MAINTAINERS? > Sure. Let me prepare the patch. Thanks, Slava. > My mail entry would be: > > John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> > > Adrian
diff --git a/fs/hfs/super.c b/fs/hfs/super.c index fe09c2093a93..4413cd8feb9e 100644 --- a/fs/hfs/super.c +++ b/fs/hfs/super.c @@ -404,6 +404,8 @@ static int hfs_init_fs_context(struct fs_context *fc) { struct hfs_sb_info *hsb; + pr_warn("The hfs filesystem is deprecated and scheduled to be removed from the kernel in 2025\n"); + hsb = kzalloc(sizeof(struct hfs_sb_info), GFP_KERNEL); if (!hsb) return -ENOMEM; diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c index 948b8aaee33e..58cff4b2a3b4 100644 --- a/fs/hfsplus/super.c +++ b/fs/hfsplus/super.c @@ -656,6 +656,8 @@ static int hfsplus_init_fs_context(struct fs_context *fc) { struct hfsplus_sb_info *sbi; + pr_warn("The hfsplus filesystem is deprecated and scheduled to be removed from the kernel in 2025\n"); + sbi = kzalloc(sizeof(struct hfsplus_sb_info), GFP_KERNEL); if (!sbi) return -ENOMEM;
Both the hfs and hfsplus filesystem have been orphaned since at least 2014, i.e., over 10 years. It's time to remove them from the kernel as they're exhibiting more and more issues and no one is stepping up to fixing them. Signed-off-by: Christian Brauner <brauner@kernel.org> --- fs/hfs/super.c | 2 ++ fs/hfsplus/super.c | 2 ++ 2 files changed, 4 insertions(+)