linux-kernel - Re: [RFC PATCH v2 0/8] staging: apfs: init APFS filesystem support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51a347ce-84d4-4698-a492-61eac2f4318e@linux.alibaba.com>
Date: Thu, 20 Mar 2025 08:43:20 +0800
From: Gao Xiang <hsiangkao@...ux.alibaba.com>
To: Ethan Carter Edwards <ethan@...ancedwards.com>, brauner@...nel.org,
 tytso@....edu, jack@...e.cz, viro@...iv.linux.org.uk
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 ernesto.mnd.fernandez@...il.com, dan.carpenter@...aro.org,
 sven@...npeter.dev, ernesto@...ellium.com, gargaditya08@...e.com,
 willy@...radead.org, asahi@...ts.linux.dev, linux-kernel@...r.kernel.org,
 linux-fsdevel@...r.kernel.org, linux-staging@...ts.linux.dev
Subject: Re: [RFC PATCH v2 0/8] staging: apfs: init APFS filesystem support



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