From: "Ernesto A. Fernández" <ernesto.mnd.fernandez@gmail.com>
To: Sven Peter <sven@svenpeter.dev>
Cc: Theodore Ts'o <tytso@mit.edu>,
Aditya Garg <gargaditya08@live.com>,
Ethan Carter Edwards <ethan@ethancedwards.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-staging@lists.linux.dev" <linux-staging@lists.linux.dev>,
"asahi@lists.linux.dev" <asahi@lists.linux.dev>,
"ernesto@corellium.com" <ernesto@corellium.com>
Subject: Re: [RFC] apfs: thoughts on upstreaming an out-of-tree module
Date: Fri, 7 Mar 2025 13:50:54 -0300 [thread overview]
Message-ID: <20250307165054.GA9774@eaf> (raw)
In-Reply-To: <4e41ef2b-7bc3-439c-9260-8a0ae835ca02@app.fastmail.com>
Hi everyone,
I don't mind putting in the work to prepare my driver for upstream. I just
can't make a case for it myself, since it sounds like a lot of work for the
reviewers and I suspect it won't be all that useful in practice.
I think the driver is reliable enough under linux-only use; the subset of
xfstests that I managed to get to run stopped finding intermittent bugs last
year. I'm less confident about our compatibility with the official driver,
since I recently fixed a terrible corruption bug for all shared containers
above 1.32 TiB in size. There is an official reference for the layout, but
it's incomplete and has a few errors.
> > (Although I suspect many external SSD's would end
> > up using some other file system that might be more portable like VFS.)
That's what I would expect too. The driver does get cloned a lot, and it's
been packaged for debian for years, so I guess some people must be using it,
but I don't really know for sure.
> > In terms of making it work with the internal SSD, it sounds like Linux
> > would need to talk to the secure enclave on the T2 Security Chip and
> > convince it to upload the encryption key into the hardware in-line
> > encryption engine.
I don't know much about the hardware side, but I think my driver will also
need some changes to get this to work. Right now we don't support any form
of encryption. It's the biggest missing feature I believe.
Ernesto
next prev parent reply other threads:[~2025-03-07 16:51 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-28 1:53 [RFC] apfs: thoughts on upstreaming an out-of-tree module Ethan Carter Edwards
2025-02-28 12:55 ` Theodore Ts'o
2025-03-01 16:26 ` Ethan Carter Edwards
2025-02-28 23:04 ` Sven Peter
2025-03-01 16:39 ` Ethan Carter Edwards
2025-03-05 7:23 ` Aditya Garg
2025-03-06 18:04 ` Theodore Ts'o
2025-03-06 19:39 ` Sven Peter
2025-03-07 16:50 ` Ernesto A. Fernández [this message]
2025-03-02 10:55 ` Dan Carpenter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250307165054.GA9774@eaf \
--to=ernesto.mnd.fernandez@gmail.com \
--cc=asahi@lists.linux.dev \
--cc=ernesto@corellium.com \
--cc=ethan@ethancedwards.com \
--cc=gargaditya08@live.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=sven@svenpeter.dev \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.