| Message ID | 20250319-apfs-v2-0-475de2e25782@ethancedwards.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | staging: apfs: init APFS filesystem support | expand |
On 2025/3/20 08:13, Ethan Carter Edwards wrote: > Hello everyone, > > In series 2, I have fixed the formatting with clang-format of the lzfse > library and fixed the comments to use linux kernel styles. I also > removed my Copyright from files where it was not appropriate. > Additionally, I removed the encode.c files as they were unused and > not compiled into the final module They should be easy enough to add > back if needed. I also rebased on Linus's tree, just in case. > Nothing broke! ;) > > I am holding off on adding Ernesto's Co-developed-by and Signed-off-by > tags until I get a better grasp of where this module is headed. I hope > to here back from Christian and the LSFMMBPF folks sometime in the next > few weeks. > > I understand the jury is still out on supporting both reading and > writing. As it stands, I have configured the code to support > reading/writing on mount, but upstream auto-rw is configurable via a > CONFIG option. Some people have expressed that they want the module > upstreamed even if only read is supported. I will stay tuned and make > changes as needed. > > Additionally, I realize that staging/ may not be the correct location > for the driver. However, I am basing my upstream process off of the > erofs process. They started in staging. I understand that the correct > tree and dir will be discussed as next weeks LSFMMBPF summit, > so I will wait on their feedback before making any moves. I don't know why erofs is related to your case here: - erofs is not a project based on reserve engineering from the beginning; it was a real productizied project initially designed for Android and got wider adoption for various use cases now; - It was a story 6 years ago (I've been actively working on this project more than 7 years and it sacrificed my extra free time and some other possibility), more recent fses instead directly land into "fs/" and it seems the preferred way. But, nevertheless, there is also some fs like ntfs3 directly into "fs/" and got some dispute; - I have no idea if you have enough professional experience to resolve apfs-specific issues properly and in time. I think it's a basic requirement for a kernel subsystem upstream maintainer now that you introduced this; - And you'd better to keep relatively active during the entire Linux kernel lifetime even that is not related to your ongoing work rather than dump and leave. Thanks, Gao Xiang
I don't think this filesystem should be merged. The real upstream is out of tree. regards, dan carpenter
Hello everyone, In series 2, I have fixed the formatting with clang-format of the lzfse library and fixed the comments to use linux kernel styles. I also removed my Copyright from files where it was not appropriate. Additionally, I removed the encode.c files as they were unused and not compiled into the final module They should be easy enough to add back if needed. I also rebased on Linus's tree, just in case. Nothing broke! ;) I am holding off on adding Ernesto's Co-developed-by and Signed-off-by tags until I get a better grasp of where this module is headed. I hope to here back from Christian and the LSFMMBPF folks sometime in the next few weeks. I understand the jury is still out on supporting both reading and writing. As it stands, I have configured the code to support reading/writing on mount, but upstream auto-rw is configurable via a CONFIG option. Some people have expressed that they want the module upstreamed even if only read is supported. I will stay tuned and make changes as needed. Additionally, I realize that staging/ may not be the correct location for the driver. However, I am basing my upstream process off of the erofs process. They started in staging. I understand that the correct tree and dir will be discussed as next weeks LSFMMBPF summit, so I will wait on their feedback before making any moves. 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. Ernesto, the original author, encouraged me to submit any code improvements upstream instead of submitting here. I am upstreaming my code improvements to his tree, but I will continue the effort here in caes upstream fs folks are interested. In any case, my goal here is to create discussion around the project and make the code better while I am at it. Some people on Asahi channels have mentioned that this driver could be helpful for implementing certain features like the fingerprint reader and simplify the boot process some. This feedback encourages me to continue with this effort. Asahi folks, keep at it, y'all are awesome. [0]: https://lore.kernel.org/lkml/20250307165054.GA9774@eaf/ Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com> --- Changes in v2: - remove Ethan copyright in files - cleanup/format lzfse code and comments - fix a few checkpatch problems - Link to v1: https://lore.kernel.org/r/20250314-apfs-v1-0-ddfaa6836b5c@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 | 1192 ++++++++ drivers/staging/apfs/apfs_raw.h | 1566 +++++++++++ drivers/staging/apfs/btree.c | 1174 ++++++++ drivers/staging/apfs/compress.c | 441 +++ drivers/staging/apfs/dir.c | 1439 ++++++++++ drivers/staging/apfs/extents.c | 2370 ++++++++++++++++ drivers/staging/apfs/file.c | 163 ++ drivers/staging/apfs/inode.c | 2234 +++++++++++++++ drivers/staging/apfs/key.c | 337 +++ drivers/staging/apfs/libzbitmap.c | 448 +++ drivers/staging/apfs/libzbitmap.h | 32 + drivers/staging/apfs/lzfse/lzfse.h | 86 + drivers/staging/apfs/lzfse/lzfse_decode.c | 66 + drivers/staging/apfs/lzfse/lzfse_decode_base.c | 725 +++++ drivers/staging/apfs/lzfse/lzfse_encode_tables.h | 224 ++ drivers/staging/apfs/lzfse/lzfse_fse.c | 214 ++ drivers/staging/apfs/lzfse/lzfse_fse.h | 632 +++++ drivers/staging/apfs/lzfse/lzfse_internal.h | 599 ++++ drivers/staging/apfs/lzfse/lzfse_tunables.h | 50 + drivers/staging/apfs/lzfse/lzvn_decode_base.c | 721 +++++ drivers/staging/apfs/lzfse/lzvn_decode_base.h | 53 + drivers/staging/apfs/lzfse/lzvn_encode_base.h | 105 + drivers/staging/apfs/message.c | 29 + drivers/staging/apfs/namei.c | 132 + drivers/staging/apfs/node.c | 2069 ++++++++++++++ drivers/staging/apfs/object.c | 315 +++ drivers/staging/apfs/snapshot.c | 683 +++++ drivers/staging/apfs/spaceman.c | 1433 ++++++++++ drivers/staging/apfs/super.c | 2098 ++++++++++++++ drivers/staging/apfs/symlink.c | 77 + drivers/staging/apfs/transaction.c | 959 +++++++ drivers/staging/apfs/unicode.c | 3156 ++++++++++++++++++++++ drivers/staging/apfs/unicode.h | 27 + drivers/staging/apfs/xattr.c | 911 +++++++ drivers/staging/apfs/xfield.c | 171 ++ 41 files changed, 27056 insertions(+) --- base-commit: a7f2e10ecd8f18b83951b0bab47ddaf48f93bf47 change-id: 20250210-apfs-9d4478785f80 Best regards,