| Message ID | 20250314-apfs-v1-0-ddfaa6836b5c@ethancedwards.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | staging: apfs: init APFS module | expand |
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
> 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> >
> 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>
> 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
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
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
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> > > >
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> > >
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
> 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.
> 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> >> >>
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,