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

Jan Kara
2025-05-13T10:44:02Z

On Tue 13-05-25 12:13:23, Nick Chan wrote:
>
> Ernesto A. Fernández 於 2025/5/13 清晨7:40 寫道:
> > Hi Yangtao,
> >
> > On Mon, May 12, 2025 at 04:11:22AM -0600, Yangtao Li wrote:
> >> I'm interested in bringing apfs upstream to the community, and perhaps
> >> slava and adrian too.
> > Do you have any particular use case in mind here? I don't mind putting in
> > the work to get the driver upstream, but I don't want to be fighting people
> > to convince them that it's needed. I'm not even sure about it myself.
>
> These are the use cases I can think of:
>
>
> 1. When running Linux on Apple Silicon Mac, accessing the xART APFS
> volume is required for enabling some SEP functionalities.
>
> 2. When running Linux on iPhone, iPad, iPod touch, Apple TV (currently
> there are Apple A7-A11 SoC support in upstream), resizing the main APFS
> volume is not feasible especially on A11 due to shenanigans with the
> encrypted data volume. So the safe ish way to store a file system on the
> disk becomes a using linux-apfs-rw on a (possibly fixed size) volume that
> only has one file and that file is used as a loopback device.
>
> (do note that the main storage do not currently work upstream and I only have storage working on A11 downstream)
>
> 3. Obviously, accessing Mac files from Linux too, not sure how big of a use case that is but apparently it is
> big enough for hfsplus to continue receive patches here and there.

I can see that accessing APFS filesystem is useful at times. But the
question is: why do we need it in the kernel? Why isn't a FUSE driver
enough? Because for relatively niche usecase like this that is a much more
acceptable (and easier to maintain) choice.

Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR