mbox series

[RFC,0/8] staging: apfs: init APFS module

Message ID 20250314-apfs-v1-0-ddfaa6836b5c@ethancedwards.com (mailing list archive)
Headers show
Series staging: apfs: init APFS module | expand

Message

Ethan Carter Edwards March 14, 2025, 9:57 p.m. UTC
Hello everyone,

This is a follow up patchset to the driver I sent an email about a few
weeks ago [0]. I understand this patchset will probably get rejected, 
but I wanted to report on what I have done thus far. I have got the 
upstream module imported and building, and it passes some basic tests 
so far (I have not tried getting XFS/FStests running yet). 

Like mentioned earlier, some of the files have been moved to folios, but
a large majority of them still use bufferheads. I would like to have
them completely removed before moved from staging/ into fs/.

I have split everything up into separate commits as best as I could.
Most of the C files rely in functions from other C files, so I included
them all in one patch/commit.

I am curious to hear everyone's thoughts on this and to start getting
the ball rolling for the code-review process. Please feel free to
include/CC anyone who may be interested in this driver/the review
process. I have included a few people, but have certainly missed others.

[0]: https://lore.kernel.org/lkml/20250307165054.GA9774@eaf/

Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>
---
Ethan Carter Edwards (8):
      staging: apfs: init lzfse compression library for APFS
      staging: apfs: init unicode.{c,h}
      staging: apfs: init apfs_raw.h to handle on-disk structures
      staging: apfs: init libzbitmap.{c,h} for decompression
      staging: apfs: init APFS
      staging: apfs: init build support for APFS
      staging: apfs: init TODO and README.rst
      MAINTAINERS: apfs: add entry and relevant information

 MAINTAINERS                                      |    6 +
 drivers/staging/Kconfig                          |    2 +
 drivers/staging/apfs/Kconfig                     |   13 +
 drivers/staging/apfs/Makefile                    |   10 +
 drivers/staging/apfs/README.rst                  |   87 +
 drivers/staging/apfs/TODO                        |    7 +
 drivers/staging/apfs/apfs.h                      | 1193 ++++++++
 drivers/staging/apfs/apfs_raw.h                  | 1567 +++++++++++
 drivers/staging/apfs/btree.c                     | 1174 ++++++++
 drivers/staging/apfs/compress.c                  |  442 +++
 drivers/staging/apfs/dir.c                       | 1440 ++++++++++
 drivers/staging/apfs/extents.c                   | 2371 ++++++++++++++++
 drivers/staging/apfs/file.c                      |  164 ++
 drivers/staging/apfs/inode.c                     | 2235 +++++++++++++++
 drivers/staging/apfs/key.c                       |  337 +++
 drivers/staging/apfs/libzbitmap.c                |  442 +++
 drivers/staging/apfs/libzbitmap.h                |   31 +
 drivers/staging/apfs/lzfse/lzfse.h               |  136 +
 drivers/staging/apfs/lzfse/lzfse_decode.c        |   74 +
 drivers/staging/apfs/lzfse/lzfse_decode_base.c   |  652 +++++
 drivers/staging/apfs/lzfse/lzfse_encode.c        |  163 ++
 drivers/staging/apfs/lzfse/lzfse_encode_base.c   |  826 ++++++
 drivers/staging/apfs/lzfse/lzfse_encode_tables.h |  218 ++
 drivers/staging/apfs/lzfse/lzfse_fse.c           |  217 ++
 drivers/staging/apfs/lzfse/lzfse_fse.h           |  606 +++++
 drivers/staging/apfs/lzfse/lzfse_internal.h      |  612 +++++
 drivers/staging/apfs/lzfse/lzfse_main.c          |  336 +++
 drivers/staging/apfs/lzfse/lzfse_tunables.h      |   60 +
 drivers/staging/apfs/lzfse/lzvn_decode_base.c    |  721 +++++
 drivers/staging/apfs/lzfse/lzvn_decode_base.h    |   68 +
 drivers/staging/apfs/lzfse/lzvn_encode_base.c    |  593 ++++
 drivers/staging/apfs/lzfse/lzvn_encode_base.h    |  116 +
 drivers/staging/apfs/message.c                   |   29 +
 drivers/staging/apfs/namei.c                     |  133 +
 drivers/staging/apfs/node.c                      | 2069 ++++++++++++++
 drivers/staging/apfs/object.c                    |  315 +++
 drivers/staging/apfs/snapshot.c                  |  684 +++++
 drivers/staging/apfs/spaceman.c                  | 1433 ++++++++++
 drivers/staging/apfs/super.c                     | 2099 ++++++++++++++
 drivers/staging/apfs/symlink.c                   |   78 +
 drivers/staging/apfs/transaction.c               |  959 +++++++
 drivers/staging/apfs/unicode.c                   | 3156 ++++++++++++++++++++++
 drivers/staging/apfs/unicode.h                   |   27 +
 drivers/staging/apfs/xattr.c                     |  912 +++++++
 drivers/staging/apfs/xfield.c                    |  171 ++
 45 files changed, 28984 insertions(+)
---
base-commit: 695caca9345a160ecd9645abab8e70cfe849e9ff
change-id: 20250210-apfs-9d4478785f80

Best regards,

Comments

Greg KH March 15, 2025, 7 a.m. UTC | #1
On Fri, Mar 14, 2025 at 05:57:46PM -0400, Ethan Carter Edwards wrote:
> Hello everyone,
> 
> This is a follow up patchset to the driver I sent an email about a few
> weeks ago [0]. I understand this patchset will probably get rejected, 
> but I wanted to report on what I have done thus far. I have got the 
> upstream module imported and building, and it passes some basic tests 
> so far (I have not tried getting XFS/FStests running yet). 
> 
> Like mentioned earlier, some of the files have been moved to folios, but
> a large majority of them still use bufferheads. I would like to have
> them completely removed before moved from staging/ into fs/.
> 
> I have split everything up into separate commits as best as I could.
> Most of the C files rely in functions from other C files, so I included
> them all in one patch/commit.
> 
> I am curious to hear everyone's thoughts on this and to start getting
> the ball rolling for the code-review process. Please feel free to
> include/CC anyone who may be interested in this driver/the review
> process. I have included a few people, but have certainly missed others.
> 
> [0]: https://lore.kernel.org/lkml/20250307165054.GA9774@eaf/
> 
> Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>

I don't mind adding this to staging from this series, thanks for
breaking it up!

But I'll wait for an ACK from the filesystem developers before doing it
as having filesystem code in drivers/staging/ feels odd, and they kind
of need to know what's going on here for when they change api stuff.

thanks,

greg k-h
Aditya Garg March 15, 2025, 7:10 a.m. UTC | #2
> On 15 Mar 2025, at 3:27 AM, Ethan Carter Edwards <ethan@ethancedwards.com> wrote:
> 
> Hello everyone,
> 
> This is a follow up patchset to the driver I sent an email about a few
> weeks ago [0]. I understand this patchset will probably get rejected, 
> but I wanted to report on what I have done thus far. I have got the 
> upstream module imported and building, and it passes some basic tests 
> so far (I have not tried getting XFS/FStests running yet). 
> 
> Like mentioned earlier, some of the files have been moved to folios, but
> a large majority of them still use bufferheads. I would like to have
> them completely removed before moved from staging/ into fs/.
> 
> I have split everything up into separate commits as best as I could.
> Most of the C files rely in functions from other C files, so I included
> them all in one patch/commit.
> 
> I am curious to hear everyone's thoughts on this and to start getting
> the ball rolling for the code-review process. Please feel free to
> include/CC anyone who may be interested in this driver/the review
> process. I have included a few people, but have certainly missed others.
> 
> [0]: https://lore.kernel.org/lkml/20250307165054.GA9774@eaf/
> 
> Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>

Why hasn’t Ernesto signed-off here, or in any patch? AFAIK, he is the author of the driver.
> ---
> Ethan Carter Edwards (8):
>      staging: apfs: init lzfse compression library for APFS
>      staging: apfs: init unicode.{c,h}
>      staging: apfs: init apfs_raw.h to handle on-disk structures
>      staging: apfs: init libzbitmap.{c,h} for decompression
>      staging: apfs: init APFS
>      staging: apfs: init build support for APFS
>      staging: apfs: init TODO and README.rst
>      MAINTAINERS: apfs: add entry and relevant information
> 
> MAINTAINERS                                      |    6 +
> drivers/staging/Kconfig                          |    2 +
> drivers/staging/apfs/Kconfig                     |   13 +
> drivers/staging/apfs/Makefile                    |   10 +
> drivers/staging/apfs/README.rst                  |   87 +
> drivers/staging/apfs/TODO                        |    7 +
> drivers/staging/apfs/apfs.h                      | 1193 ++++++++
> drivers/staging/apfs/apfs_raw.h                  | 1567 +++++++++++
> drivers/staging/apfs/btree.c                     | 1174 ++++++++
> drivers/staging/apfs/compress.c                  |  442 +++
> drivers/staging/apfs/dir.c                       | 1440 ++++++++++
> drivers/staging/apfs/extents.c                   | 2371 ++++++++++++++++
> drivers/staging/apfs/file.c                      |  164 ++
> drivers/staging/apfs/inode.c                     | 2235 +++++++++++++++
> drivers/staging/apfs/key.c                       |  337 +++
> drivers/staging/apfs/libzbitmap.c                |  442 +++
> drivers/staging/apfs/libzbitmap.h                |   31 +
> drivers/staging/apfs/lzfse/lzfse.h               |  136 +
> drivers/staging/apfs/lzfse/lzfse_decode.c        |   74 +
> drivers/staging/apfs/lzfse/lzfse_decode_base.c   |  652 +++++
> drivers/staging/apfs/lzfse/lzfse_encode.c        |  163 ++
> drivers/staging/apfs/lzfse/lzfse_encode_base.c   |  826 ++++++
> drivers/staging/apfs/lzfse/lzfse_encode_tables.h |  218 ++
> drivers/staging/apfs/lzfse/lzfse_fse.c           |  217 ++
> drivers/staging/apfs/lzfse/lzfse_fse.h           |  606 +++++
> drivers/staging/apfs/lzfse/lzfse_internal.h      |  612 +++++
> drivers/staging/apfs/lzfse/lzfse_main.c          |  336 +++
> drivers/staging/apfs/lzfse/lzfse_tunables.h      |   60 +
> drivers/staging/apfs/lzfse/lzvn_decode_base.c    |  721 +++++
> drivers/staging/apfs/lzfse/lzvn_decode_base.h    |   68 +
> drivers/staging/apfs/lzfse/lzvn_encode_base.c    |  593 ++++
> drivers/staging/apfs/lzfse/lzvn_encode_base.h    |  116 +
> drivers/staging/apfs/message.c                   |   29 +
> drivers/staging/apfs/namei.c                     |  133 +
> drivers/staging/apfs/node.c                      | 2069 ++++++++++++++
> drivers/staging/apfs/object.c                    |  315 +++
> drivers/staging/apfs/snapshot.c                  |  684 +++++
> drivers/staging/apfs/spaceman.c                  | 1433 ++++++++++
> drivers/staging/apfs/super.c                     | 2099 ++++++++++++++
> drivers/staging/apfs/symlink.c                   |   78 +
> drivers/staging/apfs/transaction.c               |  959 +++++++
> drivers/staging/apfs/unicode.c                   | 3156 ++++++++++++++++++++++
> drivers/staging/apfs/unicode.h                   |   27 +
> drivers/staging/apfs/xattr.c                     |  912 +++++++
> drivers/staging/apfs/xfield.c                    |  171 ++
> 45 files changed, 28984 insertions(+)
> ---
> base-commit: 695caca9345a160ecd9645abab8e70cfe849e9ff
> change-id: 20250210-apfs-9d4478785f80
> 
> Best regards,
> -- 
> Ethan Carter Edwards <ethan@ethancedwards.com>
>
Aditya Garg March 15, 2025, 7:21 a.m. UTC | #3
> On 15 Mar 2025, at 12:39 PM, Aditya Garg <gargaditya08@live.com> wrote:
> 
> 
> 
>> On 15 Mar 2025, at 3:27 AM, Ethan Carter Edwards <ethan@ethancedwards.com> wrote:
>> 
>> Hello everyone,
>> 
>> This is a follow up patchset to the driver I sent an email about a few
>> weeks ago [0]. I understand this patchset will probably get rejected, 
>> but I wanted to report on what I have done thus far. I have got the 
>> upstream module imported and building, and it passes some basic tests 
>> so far (I have not tried getting XFS/FStests running yet). 
>> 
>> Like mentioned earlier, some of the files have been moved to folios, but
>> a large majority of them still use bufferheads. I would like to have
>> them completely removed before moved from staging/ into fs/.
>> 
>> I have split everything up into separate commits as best as I could.
>> Most of the C files rely in functions from other C files, so I included
>> them all in one patch/commit.
>> 
>> I am curious to hear everyone's thoughts on this and to start getting
>> the ball rolling for the code-review process. Please feel free to
>> include/CC anyone who may be interested in this driver/the review
>> process. I have included a few people, but have certainly missed others.
>> 
>> [0]: https://lore.kernel.org/lkml/20250307165054.GA9774@eaf/
>> 
>> Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>
> 
> Why hasn’t Ernesto signed-off here, or in any patch? AFAIK, he is the author of the driver.

I can also see your Copyright at some places, which I didn't find in the upstream repo. Did you add some code change?

IMO, if you are just maintaining it, doesn't mean you add your copyright. Eg: I maintain the appletbdrm driver, but I didn't write or add anything special in it, so it doesn’t have my copyright.

Also, did you ask Ernesto whether he wants to be a co maintainer?

>> ---
>> Ethan Carter Edwards (8):
>>    staging: apfs: init lzfse compression library for APFS
>>    staging: apfs: init unicode.{c,h}
>>    staging: apfs: init apfs_raw.h to handle on-disk structures
>>    staging: apfs: init libzbitmap.{c,h} for decompression
>>    staging: apfs: init APFS
>>    staging: apfs: init build support for APFS
>>    staging: apfs: init TODO and README.rst
>>    MAINTAINERS: apfs: add entry and relevant information
>> 
>> MAINTAINERS                                      |    6 +
>> drivers/staging/Kconfig                          |    2 +
>> drivers/staging/apfs/Kconfig                     |   13 +
>> drivers/staging/apfs/Makefile                    |   10 +
>> drivers/staging/apfs/README.rst                  |   87 +
>> drivers/staging/apfs/TODO                        |    7 +
>> drivers/staging/apfs/apfs.h                      | 1193 ++++++++
>> drivers/staging/apfs/apfs_raw.h                  | 1567 +++++++++++
>> drivers/staging/apfs/btree.c                     | 1174 ++++++++
>> drivers/staging/apfs/compress.c                  |  442 +++
>> drivers/staging/apfs/dir.c                       | 1440 ++++++++++
>> drivers/staging/apfs/extents.c                   | 2371 ++++++++++++++++
>> drivers/staging/apfs/file.c                      |  164 ++
>> drivers/staging/apfs/inode.c                     | 2235 +++++++++++++++
>> drivers/staging/apfs/key.c                       |  337 +++
>> drivers/staging/apfs/libzbitmap.c                |  442 +++
>> drivers/staging/apfs/libzbitmap.h                |   31 +
>> drivers/staging/apfs/lzfse/lzfse.h               |  136 +
>> drivers/staging/apfs/lzfse/lzfse_decode.c        |   74 +
>> drivers/staging/apfs/lzfse/lzfse_decode_base.c   |  652 +++++
>> drivers/staging/apfs/lzfse/lzfse_encode.c        |  163 ++
>> drivers/staging/apfs/lzfse/lzfse_encode_base.c   |  826 ++++++
>> drivers/staging/apfs/lzfse/lzfse_encode_tables.h |  218 ++
>> drivers/staging/apfs/lzfse/lzfse_fse.c           |  217 ++
>> drivers/staging/apfs/lzfse/lzfse_fse.h           |  606 +++++
>> drivers/staging/apfs/lzfse/lzfse_internal.h      |  612 +++++
>> drivers/staging/apfs/lzfse/lzfse_main.c          |  336 +++
>> drivers/staging/apfs/lzfse/lzfse_tunables.h      |   60 +
>> drivers/staging/apfs/lzfse/lzvn_decode_base.c    |  721 +++++
>> drivers/staging/apfs/lzfse/lzvn_decode_base.h    |   68 +
>> drivers/staging/apfs/lzfse/lzvn_encode_base.c    |  593 ++++
>> drivers/staging/apfs/lzfse/lzvn_encode_base.h    |  116 +
>> drivers/staging/apfs/message.c                   |   29 +
>> drivers/staging/apfs/namei.c                     |  133 +
>> drivers/staging/apfs/node.c                      | 2069 ++++++++++++++
>> drivers/staging/apfs/object.c                    |  315 +++
>> drivers/staging/apfs/snapshot.c                  |  684 +++++
>> drivers/staging/apfs/spaceman.c                  | 1433 ++++++++++
>> drivers/staging/apfs/super.c                     | 2099 ++++++++++++++
>> drivers/staging/apfs/symlink.c                   |   78 +
>> drivers/staging/apfs/transaction.c               |  959 +++++++
>> drivers/staging/apfs/unicode.c                   | 3156 ++++++++++++++++++++++
>> drivers/staging/apfs/unicode.h                   |   27 +
>> drivers/staging/apfs/xattr.c                     |  912 +++++++
>> drivers/staging/apfs/xfield.c                    |  171 ++
>> 45 files changed, 28984 insertions(+)
>> ---
>> base-commit: 695caca9345a160ecd9645abab8e70cfe849e9ff
>> change-id: 20250210-apfs-9d4478785f80
>> 
>> Best regards,
>> -- 
>> Ethan Carter Edwards <ethan@ethancedwards.com>
Christian Brauner March 15, 2025, 9:18 a.m. UTC | #4
> But I'll wait for an ACK from the filesystem developers before doing it
> as having filesystem code in drivers/staging/ feels odd, and they kind
> of need to know what's going on here for when they change api stuff.

Sorry, I don't want new filesystems going through the generic staging
tree. Next week during LSFMM we can discuss a filesystem specific
staging tree that is directly maintained as part of fs so it's tightly
integrated. We're going to talk about two new filesystems anyway.

Thanks!
Christian
Greg KH March 15, 2025, 9:32 a.m. UTC | #5
On Sat, Mar 15, 2025 at 10:18:23AM +0100, Christian Brauner wrote:
> > But I'll wait for an ACK from the filesystem developers before doing it
> > as having filesystem code in drivers/staging/ feels odd, and they kind
> > of need to know what's going on here for when they change api stuff.
> 
> Sorry, I don't want new filesystems going through the generic staging
> tree. Next week during LSFMM we can discuss a filesystem specific
> staging tree that is directly maintained as part of fs so it's tightly
> integrated. We're going to talk about two new filesystems anyway.

Great, then I'll not worry about this patch series at all, thanks!

greg k-h
Ethan Carter Edwards March 15, 2025, 2:04 p.m. UTC | #6
On 25/03/15 08:00AM, Greg Kroah-Hartman wrote:
> On Fri, Mar 14, 2025 at 05:57:46PM -0400, Ethan Carter Edwards wrote:
> > Hello everyone,
> > 
> > This is a follow up patchset to the driver I sent an email about a few
> > weeks ago [0]. I understand this patchset will probably get rejected, 
> > but I wanted to report on what I have done thus far. I have got the 
> > upstream module imported and building, and it passes some basic tests 
> > so far (I have not tried getting XFS/FStests running yet). 
> > 
> > Like mentioned earlier, some of the files have been moved to folios, but
> > a large majority of them still use bufferheads. I would like to have
> > them completely removed before moved from staging/ into fs/.
> > 
> > I have split everything up into separate commits as best as I could.
> > Most of the C files rely in functions from other C files, so I included
> > them all in one patch/commit.
> > 
> > I am curious to hear everyone's thoughts on this and to start getting
> > the ball rolling for the code-review process. Please feel free to
> > include/CC anyone who may be interested in this driver/the review
> > process. I have included a few people, but have certainly missed others.
> > 
> > [0]: https://lore.kernel.org/lkml/20250307165054.GA9774@eaf/
> > 
> > Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>
> 
> I don't mind adding this to staging from this series, thanks for
> breaking it up!
> 
> But I'll wait for an ACK from the filesystem developers before doing it
> as having filesystem code in drivers/staging/ feels odd, and they kind
> of need to know what's going on here for when they change api stuff.

No problem. That makes sense. I used the process that erofs used as a
reference for how the fs development lifecycle should look. They started
in staging/ and ended in fs/ after. 

Thanks,
Ethan

> 
> thanks,
> 
> greg k-h
Ethan Carter Edwards March 15, 2025, 2:06 p.m. UTC | #7
On 25/03/15 07:10AM, Aditya Garg wrote:
> 
> 
> > On 15 Mar 2025, at 3:27 AM, Ethan Carter Edwards <ethan@ethancedwards.com> wrote:
> > 
> > Hello everyone,
> > 
> > This is a follow up patchset to the driver I sent an email about a few
> > weeks ago [0]. I understand this patchset will probably get rejected, 
> > but I wanted to report on what I have done thus far. I have got the 
> > upstream module imported and building, and it passes some basic tests 
> > so far (I have not tried getting XFS/FStests running yet). 
> > 
> > Like mentioned earlier, some of the files have been moved to folios, but
> > a large majority of them still use bufferheads. I would like to have
> > them completely removed before moved from staging/ into fs/.
> > 
> > I have split everything up into separate commits as best as I could.
> > Most of the C files rely in functions from other C files, so I included
> > them all in one patch/commit.
> > 
> > I am curious to hear everyone's thoughts on this and to start getting
> > the ball rolling for the code-review process. Please feel free to
> > include/CC anyone who may be interested in this driver/the review
> > process. I have included a few people, but have certainly missed others.
> > 
> > [0]: https://lore.kernel.org/lkml/20250307165054.GA9774@eaf/
> > 
> > Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>
> 
> Why hasn’t Ernesto signed-off here, or in any patch? AFAIK, he is the author of the driver.

That is correct. He originally authored the code. I can coordinate with
him and go through the process with him if he is willing (understandable
if not). I only did some slight refactors to get the code compiling.

Thanks,
Ethan

> > ---
> > Ethan Carter Edwards (8):
> >      staging: apfs: init lzfse compression library for APFS
> >      staging: apfs: init unicode.{c,h}
> >      staging: apfs: init apfs_raw.h to handle on-disk structures
> >      staging: apfs: init libzbitmap.{c,h} for decompression
> >      staging: apfs: init APFS
> >      staging: apfs: init build support for APFS
> >      staging: apfs: init TODO and README.rst
> >      MAINTAINERS: apfs: add entry and relevant information
> > 
> > MAINTAINERS                                      |    6 +
> > drivers/staging/Kconfig                          |    2 +
> > drivers/staging/apfs/Kconfig                     |   13 +
> > drivers/staging/apfs/Makefile                    |   10 +
> > drivers/staging/apfs/README.rst                  |   87 +
> > drivers/staging/apfs/TODO                        |    7 +
> > drivers/staging/apfs/apfs.h                      | 1193 ++++++++
> > drivers/staging/apfs/apfs_raw.h                  | 1567 +++++++++++
> > drivers/staging/apfs/btree.c                     | 1174 ++++++++
> > drivers/staging/apfs/compress.c                  |  442 +++
> > drivers/staging/apfs/dir.c                       | 1440 ++++++++++
> > drivers/staging/apfs/extents.c                   | 2371 ++++++++++++++++
> > drivers/staging/apfs/file.c                      |  164 ++
> > drivers/staging/apfs/inode.c                     | 2235 +++++++++++++++
> > drivers/staging/apfs/key.c                       |  337 +++
> > drivers/staging/apfs/libzbitmap.c                |  442 +++
> > drivers/staging/apfs/libzbitmap.h                |   31 +
> > drivers/staging/apfs/lzfse/lzfse.h               |  136 +
> > drivers/staging/apfs/lzfse/lzfse_decode.c        |   74 +
> > drivers/staging/apfs/lzfse/lzfse_decode_base.c   |  652 +++++
> > drivers/staging/apfs/lzfse/lzfse_encode.c        |  163 ++
> > drivers/staging/apfs/lzfse/lzfse_encode_base.c   |  826 ++++++
> > drivers/staging/apfs/lzfse/lzfse_encode_tables.h |  218 ++
> > drivers/staging/apfs/lzfse/lzfse_fse.c           |  217 ++
> > drivers/staging/apfs/lzfse/lzfse_fse.h           |  606 +++++
> > drivers/staging/apfs/lzfse/lzfse_internal.h      |  612 +++++
> > drivers/staging/apfs/lzfse/lzfse_main.c          |  336 +++
> > drivers/staging/apfs/lzfse/lzfse_tunables.h      |   60 +
> > drivers/staging/apfs/lzfse/lzvn_decode_base.c    |  721 +++++
> > drivers/staging/apfs/lzfse/lzvn_decode_base.h    |   68 +
> > drivers/staging/apfs/lzfse/lzvn_encode_base.c    |  593 ++++
> > drivers/staging/apfs/lzfse/lzvn_encode_base.h    |  116 +
> > drivers/staging/apfs/message.c                   |   29 +
> > drivers/staging/apfs/namei.c                     |  133 +
> > drivers/staging/apfs/node.c                      | 2069 ++++++++++++++
> > drivers/staging/apfs/object.c                    |  315 +++
> > drivers/staging/apfs/snapshot.c                  |  684 +++++
> > drivers/staging/apfs/spaceman.c                  | 1433 ++++++++++
> > drivers/staging/apfs/super.c                     | 2099 ++++++++++++++
> > drivers/staging/apfs/symlink.c                   |   78 +
> > drivers/staging/apfs/transaction.c               |  959 +++++++
> > drivers/staging/apfs/unicode.c                   | 3156 ++++++++++++++++++++++
> > drivers/staging/apfs/unicode.h                   |   27 +
> > drivers/staging/apfs/xattr.c                     |  912 +++++++
> > drivers/staging/apfs/xfield.c                    |  171 ++
> > 45 files changed, 28984 insertions(+)
> > ---
> > base-commit: 695caca9345a160ecd9645abab8e70cfe849e9ff
> > change-id: 20250210-apfs-9d4478785f80
> > 
> > Best regards,
> > -- 
> > Ethan Carter Edwards <ethan@ethancedwards.com>
> > 
>
Ethan Carter Edwards March 15, 2025, 2:12 p.m. UTC | #8
On 25/03/15 07:21AM, Aditya Garg wrote:
> 
> 
> > On 15 Mar 2025, at 12:39 PM, Aditya Garg <gargaditya08@live.com> wrote:
> > 
> > 
> > 
> >> On 15 Mar 2025, at 3:27 AM, Ethan Carter Edwards <ethan@ethancedwards.com> wrote:
> >> 
> >> Hello everyone,
> >> 
> >> This is a follow up patchset to the driver I sent an email about a few
> >> weeks ago [0]. I understand this patchset will probably get rejected, 
> >> but I wanted to report on what I have done thus far. I have got the 
> >> upstream module imported and building, and it passes some basic tests 
> >> so far (I have not tried getting XFS/FStests running yet). 
> >> 
> >> Like mentioned earlier, some of the files have been moved to folios, but
> >> a large majority of them still use bufferheads. I would like to have
> >> them completely removed before moved from staging/ into fs/.
> >> 
> >> I have split everything up into separate commits as best as I could.
> >> Most of the C files rely in functions from other C files, so I included
> >> them all in one patch/commit.
> >> 
> >> I am curious to hear everyone's thoughts on this and to start getting
> >> the ball rolling for the code-review process. Please feel free to
> >> include/CC anyone who may be interested in this driver/the review
> >> process. I have included a few people, but have certainly missed others.
> >> 
> >> [0]: https://lore.kernel.org/lkml/20250307165054.GA9774@eaf/
> >> 
> >> Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>
> > 
> > Why hasn’t Ernesto signed-off here, or in any patch? AFAIK, he is the author of the driver.
> 
> I can also see your Copyright at some places, which I didn't find in the upstream repo. Did you add some code change?

Yes, there were some slight refactors in some files to get the code
compiling. I only added my copyright in files where I changed things. I
can remove them. I was not sure what to do.

> 
> IMO, if you are just maintaining it, doesn't mean you add your copyright. Eg: I maintain the appletbdrm driver, but I didn't write or add anything special in it, so it doesn’t have my copyright.

Sure. That is logical. I'll remove them in the next series.

> 
> Also, did you ask Ernesto whether he wants to be a co maintainer?
> 

Kinda? https://github.com/linux-apfs/linux-apfs-rw/issues/68#issuecomment-2608400271
See that link. I did not really get an answer, so I decided to start the
process anyways. If he does not want to co-maintain, I completely
understand. I don't want to assume he is willing to. Ultimately, it is
up to him.

Thanks,
Ethan

> >> ---
> >> Ethan Carter Edwards (8):
> >>    staging: apfs: init lzfse compression library for APFS
> >>    staging: apfs: init unicode.{c,h}
> >>    staging: apfs: init apfs_raw.h to handle on-disk structures
> >>    staging: apfs: init libzbitmap.{c,h} for decompression
> >>    staging: apfs: init APFS
> >>    staging: apfs: init build support for APFS
> >>    staging: apfs: init TODO and README.rst
> >>    MAINTAINERS: apfs: add entry and relevant information
> >> 
> >> MAINTAINERS                                      |    6 +
> >> drivers/staging/Kconfig                          |    2 +
> >> drivers/staging/apfs/Kconfig                     |   13 +
> >> drivers/staging/apfs/Makefile                    |   10 +
> >> drivers/staging/apfs/README.rst                  |   87 +
> >> drivers/staging/apfs/TODO                        |    7 +
> >> drivers/staging/apfs/apfs.h                      | 1193 ++++++++
> >> drivers/staging/apfs/apfs_raw.h                  | 1567 +++++++++++
> >> drivers/staging/apfs/btree.c                     | 1174 ++++++++
> >> drivers/staging/apfs/compress.c                  |  442 +++
> >> drivers/staging/apfs/dir.c                       | 1440 ++++++++++
> >> drivers/staging/apfs/extents.c                   | 2371 ++++++++++++++++
> >> drivers/staging/apfs/file.c                      |  164 ++
> >> drivers/staging/apfs/inode.c                     | 2235 +++++++++++++++
> >> drivers/staging/apfs/key.c                       |  337 +++
> >> drivers/staging/apfs/libzbitmap.c                |  442 +++
> >> drivers/staging/apfs/libzbitmap.h                |   31 +
> >> drivers/staging/apfs/lzfse/lzfse.h               |  136 +
> >> drivers/staging/apfs/lzfse/lzfse_decode.c        |   74 +
> >> drivers/staging/apfs/lzfse/lzfse_decode_base.c   |  652 +++++
> >> drivers/staging/apfs/lzfse/lzfse_encode.c        |  163 ++
> >> drivers/staging/apfs/lzfse/lzfse_encode_base.c   |  826 ++++++
> >> drivers/staging/apfs/lzfse/lzfse_encode_tables.h |  218 ++
> >> drivers/staging/apfs/lzfse/lzfse_fse.c           |  217 ++
> >> drivers/staging/apfs/lzfse/lzfse_fse.h           |  606 +++++
> >> drivers/staging/apfs/lzfse/lzfse_internal.h      |  612 +++++
> >> drivers/staging/apfs/lzfse/lzfse_main.c          |  336 +++
> >> drivers/staging/apfs/lzfse/lzfse_tunables.h      |   60 +
> >> drivers/staging/apfs/lzfse/lzvn_decode_base.c    |  721 +++++
> >> drivers/staging/apfs/lzfse/lzvn_decode_base.h    |   68 +
> >> drivers/staging/apfs/lzfse/lzvn_encode_base.c    |  593 ++++
> >> drivers/staging/apfs/lzfse/lzvn_encode_base.h    |  116 +
> >> drivers/staging/apfs/message.c                   |   29 +
> >> drivers/staging/apfs/namei.c                     |  133 +
> >> drivers/staging/apfs/node.c                      | 2069 ++++++++++++++
> >> drivers/staging/apfs/object.c                    |  315 +++
> >> drivers/staging/apfs/snapshot.c                  |  684 +++++
> >> drivers/staging/apfs/spaceman.c                  | 1433 ++++++++++
> >> drivers/staging/apfs/super.c                     | 2099 ++++++++++++++
> >> drivers/staging/apfs/symlink.c                   |   78 +
> >> drivers/staging/apfs/transaction.c               |  959 +++++++
> >> drivers/staging/apfs/unicode.c                   | 3156 ++++++++++++++++++++++
> >> drivers/staging/apfs/unicode.h                   |   27 +
> >> drivers/staging/apfs/xattr.c                     |  912 +++++++
> >> drivers/staging/apfs/xfield.c                    |  171 ++
> >> 45 files changed, 28984 insertions(+)
> >> ---
> >> base-commit: 695caca9345a160ecd9645abab8e70cfe849e9ff
> >> change-id: 20250210-apfs-9d4478785f80
> >> 
> >> Best regards,
> >> -- 
> >> Ethan Carter Edwards <ethan@ethancedwards.com>
> 
>
Ethan Carter Edwards March 15, 2025, 2:13 p.m. UTC | #9
On 25/03/15 10:18AM, Christian Brauner wrote:
> > But I'll wait for an ACK from the filesystem developers before doing it
> > as having filesystem code in drivers/staging/ feels odd, and they kind
> > of need to know what's going on here for when they change api stuff.
> 
> Sorry, I don't want new filesystems going through the generic staging
> tree. Next week during LSFMM we can discuss a filesystem specific
> staging tree that is directly maintained as part of fs so it's tightly
> integrated. We're going to talk about two new filesystems anyway.

No problem! I understand. I just wanted to get the ball rolling and
start the conversation about this process. I am eager to hear back.

Thanks,
Ethan

> 
> Thanks!
> Christian
Aditya Garg March 15, 2025, 2:34 p.m. UTC | #10
> On 15 Mar 2025, at 7:42 PM, Ethan Carter Edwards <ethan@ethancedwards.com> wrote:
> 
> On 25/03/15 07:21AM, Aditya Garg wrote:
>> 
>> 
>>>> On 15 Mar 2025, at 12:39 PM, Aditya Garg <gargaditya08@live.com> wrote:
>>> 
>>> 
>>> 
>>>> On 15 Mar 2025, at 3:27 AM, Ethan Carter Edwards <ethan@ethancedwards.com> wrote:
>>>> 
>>>> Hello everyone,
>>>> 
>>>> This is a follow up patchset to the driver I sent an email about a few
>>>> weeks ago [0]. I understand this patchset will probably get rejected,
>>>> but I wanted to report on what I have done thus far. I have got the
>>>> upstream module imported and building, and it passes some basic tests
>>>> so far (I have not tried getting XFS/FStests running yet).
>>>> 
>>>> Like mentioned earlier, some of the files have been moved to folios, but
>>>> a large majority of them still use bufferheads. I would like to have
>>>> them completely removed before moved from staging/ into fs/.
>>>> 
>>>> I have split everything up into separate commits as best as I could.
>>>> Most of the C files rely in functions from other C files, so I included
>>>> them all in one patch/commit.
>>>> 
>>>> I am curious to hear everyone's thoughts on this and to start getting
>>>> the ball rolling for the code-review process. Please feel free to
>>>> include/CC anyone who may be interested in this driver/the review
>>>> process. I have included a few people, but have certainly missed others.
>>>> 
>>>> [0]: https://lore.kernel.org/lkml/20250307165054.GA9774@eaf/
>>>> 
>>>> Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>
>>> 
>>> Why hasn’t Ernesto signed-off here, or in any patch? AFAIK, he is the author of the driver.
>> 
>> I can also see your Copyright at some places, which I didn't find in the upstream repo. Did you add some code change?
> 
> Yes, there were some slight refactors in some files to get the code
> compiling. I only added my copyright in files where I changed things. I
> can remove them. I was not sure what to do.
> 
>> 
>> IMO, if you are just maintaining it, doesn't mean you add your copyright. Eg: I maintain the appletbdrm driver, but I didn't write or add anything special in it, so it doesn’t have my copyright.
> 
> Sure. That is logical. I'll remove them in the next series.
> 
>> 
>> Also, did you ask Ernesto whether he wants to be a co maintainer?
>> 
> 
> Kinda? https://github.com/linux-apfs/linux-apfs-rw/issues/68#issuecomment-2608400271
> See that link. I did not really get an answer, so I decided to start the
> process anyways. If he does not want to co-maintain, I completely
> understand. I don't want to assume he is willing to. Ultimately, it is
> up to him.

I see that Ernesto signs all his commits, giving you legally an option to sign off the series on his behalf. Also, the repository that GPL2 license, making things more easier. But ethically, I would prefer to have an ack or go ahead from ernesto if possible. I myself have been in situations where people write a driver, and disappear. Their sign off on that driver commits and GPL2 license is what makes things legal then.

So in a nutshell, all commits should have a signed-off-by from ernesto, especially when he is signing the commits in the GitHub repository. And an ack from him on LKML would be appreciated.

P.S. this is my interpretation of all the legal stuff and is followed by me on Linux, after all there is no clear documentation I have encountered in such cases, but the main take depends on the upstream maintainers.
Aditya Garg March 15, 2025, 2:35 p.m. UTC | #11
> On 15 Mar 2025, at 7:42 PM, Ethan Carter Edwards <ethan@ethancedwards.com> wrote:
> 
> On 25/03/15 07:21AM, Aditya Garg wrote:
>> 
>> 
>>>> On 15 Mar 2025, at 12:39 PM, Aditya Garg <gargaditya08@live.com> wrote:
>>> 
>>> 
>>> 
>>>> On 15 Mar 2025, at 3:27 AM, Ethan Carter Edwards <ethan@ethancedwards.com> wrote:
>>>> 
>>>> Hello everyone,
>>>> 
>>>> This is a follow up patchset to the driver I sent an email about a few
>>>> weeks ago [0]. I understand this patchset will probably get rejected,
>>>> but I wanted to report on what I have done thus far. I have got the
>>>> upstream module imported and building, and it passes some basic tests
>>>> so far (I have not tried getting XFS/FStests running yet).
>>>> 
>>>> Like mentioned earlier, some of the files have been moved to folios, but
>>>> a large majority of them still use bufferheads. I would like to have
>>>> them completely removed before moved from staging/ into fs/.
>>>> 
>>>> I have split everything up into separate commits as best as I could.
>>>> Most of the C files rely in functions from other C files, so I included
>>>> them all in one patch/commit.
>>>> 
>>>> I am curious to hear everyone's thoughts on this and to start getting
>>>> the ball rolling for the code-review process. Please feel free to
>>>> include/CC anyone who may be interested in this driver/the review
>>>> process. I have included a few people, but have certainly missed others.
>>>> 
>>>> [0]: https://lore.kernel.org/lkml/20250307165054.GA9774@eaf/
>>>> 
>>>> Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>
>>> 
>>> Why hasn’t Ernesto signed-off here, or in any patch? AFAIK, he is the author of the driver.
>> 
>> I can also see your Copyright at some places, which I didn't find in the upstream repo. Did you add some code change?
> 
> Yes, there were some slight refactors in some files to get the code
> compiling. I only added my copyright in files where I changed things. I
> can remove them. I was not sure what to do.

By this logic, every contributor to the Linux kernel should have their copyright on that driver :)
> 
>> 
>> IMO, if you are just maintaining it, doesn't mean you add your copyright. Eg: I maintain the appletbdrm driver, but I didn't write or add anything special in it, so it doesn’t have my copyright.
> 
> Sure. That is logical. I'll remove them in the next series.
> 
>> 
>> Also, did you ask Ernesto whether he wants to be a co maintainer?
>> 
> 
> Kinda? https://github.com/linux-apfs/linux-apfs-rw/issues/68#issuecomment-2608400271
> See that link. I did not really get an answer, so I decided to start the
> process anyways. If he does not want to co-maintain, I completely
> understand. I don't want to assume he is willing to. Ultimately, it is
> up to him.
> 
> Thanks,
> Ethan
> 
>>>> ---
>>>> Ethan Carter Edwards (8):
>>>>   staging: apfs: init lzfse compression library for APFS
>>>>   staging: apfs: init unicode.{c,h}
>>>>   staging: apfs: init apfs_raw.h to handle on-disk structures
>>>>   staging: apfs: init libzbitmap.{c,h} for decompression
>>>>   staging: apfs: init APFS
>>>>   staging: apfs: init build support for APFS
>>>>   staging: apfs: init TODO and README.rst
>>>>   MAINTAINERS: apfs: add entry and relevant information
>>>> 
>>>> MAINTAINERS                                      |    6 +
>>>> drivers/staging/Kconfig                          |    2 +
>>>> drivers/staging/apfs/Kconfig                     |   13 +
>>>> drivers/staging/apfs/Makefile                    |   10 +
>>>> drivers/staging/apfs/README.rst                  |   87 +
>>>> drivers/staging/apfs/TODO                        |    7 +
>>>> drivers/staging/apfs/apfs.h                      | 1193 ++++++++
>>>> drivers/staging/apfs/apfs_raw.h                  | 1567 +++++++++++
>>>> drivers/staging/apfs/btree.c                     | 1174 ++++++++
>>>> drivers/staging/apfs/compress.c                  |  442 +++
>>>> drivers/staging/apfs/dir.c                       | 1440 ++++++++++
>>>> drivers/staging/apfs/extents.c                   | 2371 ++++++++++++++++
>>>> drivers/staging/apfs/file.c                      |  164 ++
>>>> drivers/staging/apfs/inode.c                     | 2235 +++++++++++++++
>>>> drivers/staging/apfs/key.c                       |  337 +++
>>>> drivers/staging/apfs/libzbitmap.c                |  442 +++
>>>> drivers/staging/apfs/libzbitmap.h                |   31 +
>>>> drivers/staging/apfs/lzfse/lzfse.h               |  136 +
>>>> drivers/staging/apfs/lzfse/lzfse_decode.c        |   74 +
>>>> drivers/staging/apfs/lzfse/lzfse_decode_base.c   |  652 +++++
>>>> drivers/staging/apfs/lzfse/lzfse_encode.c        |  163 ++
>>>> drivers/staging/apfs/lzfse/lzfse_encode_base.c   |  826 ++++++
>>>> drivers/staging/apfs/lzfse/lzfse_encode_tables.h |  218 ++
>>>> drivers/staging/apfs/lzfse/lzfse_fse.c           |  217 ++
>>>> drivers/staging/apfs/lzfse/lzfse_fse.h           |  606 +++++
>>>> drivers/staging/apfs/lzfse/lzfse_internal.h      |  612 +++++
>>>> drivers/staging/apfs/lzfse/lzfse_main.c          |  336 +++
>>>> drivers/staging/apfs/lzfse/lzfse_tunables.h      |   60 +
>>>> drivers/staging/apfs/lzfse/lzvn_decode_base.c    |  721 +++++
>>>> drivers/staging/apfs/lzfse/lzvn_decode_base.h    |   68 +
>>>> drivers/staging/apfs/lzfse/lzvn_encode_base.c    |  593 ++++
>>>> drivers/staging/apfs/lzfse/lzvn_encode_base.h    |  116 +
>>>> drivers/staging/apfs/message.c                   |   29 +
>>>> drivers/staging/apfs/namei.c                     |  133 +
>>>> drivers/staging/apfs/node.c                      | 2069 ++++++++++++++
>>>> drivers/staging/apfs/object.c                    |  315 +++
>>>> drivers/staging/apfs/snapshot.c                  |  684 +++++
>>>> drivers/staging/apfs/spaceman.c                  | 1433 ++++++++++
>>>> drivers/staging/apfs/super.c                     | 2099 ++++++++++++++
>>>> drivers/staging/apfs/symlink.c                   |   78 +
>>>> drivers/staging/apfs/transaction.c               |  959 +++++++
>>>> drivers/staging/apfs/unicode.c                   | 3156 ++++++++++++++++++++++
>>>> drivers/staging/apfs/unicode.h                   |   27 +
>>>> drivers/staging/apfs/xattr.c                     |  912 +++++++
>>>> drivers/staging/apfs/xfield.c                    |  171 ++
>>>> 45 files changed, 28984 insertions(+)
>>>> ---
>>>> base-commit: 695caca9345a160ecd9645abab8e70cfe849e9ff
>>>> change-id: 20250210-apfs-9d4478785f80
>>>> 
>>>> Best regards,
>>>> --
>>>> Ethan Carter Edwards <ethan@ethancedwards.com>
>> 
>>