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
