public inbox for linux-staging@lists.linux.dev
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Ethan Carter Edwards <ethan@ethancedwards.com>
Cc: tytso@mit.edu, ernesto.mnd.fernandez@gmail.com,
	dan.carpenter@linaro.org, sven@svenpeter.dev,
	ernesto@corellium.com, gargaditya08@live.com,
	willy@infradead.org, asahi@lists.linux.dev,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-staging@lists.linux.dev
Subject: Re: [RFC PATCH 0/8] staging: apfs: init APFS module
Date: Sat, 15 Mar 2025 08:00:54 +0100	[thread overview]
Message-ID: <2025031529-greedless-jingle-1f3b@gregkh> (raw)
In-Reply-To: <20250314-apfs-v1-0-ddfaa6836b5c@ethancedwards.com>

On Fri, Mar 14, 2025 at 05:57:46PM -0400, Ethan Carter Edwards wrote:
> Hello everyone,
> 
> This is a follow up patchset to the driver I sent an email about a few
> weeks ago [0]. I understand this patchset will probably get rejected, 
> but I wanted to report on what I have done thus far. I have got the 
> upstream module imported and building, and it passes some basic tests 
> so far (I have not tried getting XFS/FStests running yet). 
> 
> Like mentioned earlier, some of the files have been moved to folios, but
> a large majority of them still use bufferheads. I would like to have
> them completely removed before moved from staging/ into fs/.
> 
> I have split everything up into separate commits as best as I could.
> Most of the C files rely in functions from other C files, so I included
> them all in one patch/commit.
> 
> 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.
> 
> [0]: https://lore.kernel.org/lkml/20250307165054.GA9774@eaf/
> 
> Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>

I don't mind adding this to staging from this series, thanks for
breaking it up!

But I'll wait for an ACK from the filesystem developers before doing it
as having filesystem code in drivers/staging/ feels odd, and they kind
of need to know what's going on here for when they change api stuff.

thanks,

greg k-h

  parent reply	other threads:[~2025-03-15  7:00 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-14 21:57 [RFC PATCH 0/8] staging: apfs: init APFS module Ethan Carter Edwards
2025-03-14 21:57 ` [PATCH RFC 1/8] staging: apfs: init lzfse compression library for APFS Ethan Carter Edwards
2025-03-15  7:12   ` Aditya Garg
2025-03-15 14:08     ` Ethan Carter Edwards
2025-03-15  9:41   ` Dan Carpenter
2025-03-15 14:14     ` Ethan Carter Edwards
2025-03-14 21:57 ` [PATCH RFC 2/8] staging: apfs: init unicode.{c,h} Ethan Carter Edwards
2025-03-14 21:57 ` [PATCH RFC 3/8] staging: apfs: init apfs_raw.h to handle on-disk structures Ethan Carter Edwards
2025-03-14 21:57 ` [PATCH RFC 4/8] staging: apfs: init libzbitmap.{c,h} for decompression Ethan Carter Edwards
2025-03-14 21:57 ` [PATCH RFC 5/8] staging: apfs: init APFS Ethan Carter Edwards
2025-03-14 21:57 ` [PATCH RFC 6/8] staging: apfs: init build support for APFS Ethan Carter Edwards
2025-03-14 21:57 ` [PATCH RFC 7/8] staging: apfs: init TODO and README.rst Ethan Carter Edwards
2025-03-14 21:57 ` [PATCH RFC 8/8] MAINTAINERS: apfs: add entry and relevant information Ethan Carter Edwards
2025-03-15  7:00 ` Greg Kroah-Hartman [this message]
2025-03-15  9:18   ` [RFC PATCH 0/8] staging: apfs: init APFS module Christian Brauner
2025-03-15  9:32     ` Greg Kroah-Hartman
2025-03-15 14:13     ` Ethan Carter Edwards
2025-03-15 14:04   ` Ethan Carter Edwards
2025-03-15  7:10 ` Aditya Garg
2025-03-15  7:21   ` Aditya Garg
2025-03-15 14:12     ` Ethan Carter Edwards
2025-03-15 14:34       ` Aditya Garg
2025-03-15 14:35       ` Aditya Garg
2025-03-15 14:06   ` Ethan Carter Edwards
2025-03-16  3:31 ` Ernesto A. Fernández
2025-03-16  6:31   ` Aditya Garg
2025-03-16 15:48     ` Ethan Carter Edwards

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=2025031529-greedless-jingle-1f3b@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=asahi@lists.linux.dev \
    --cc=dan.carpenter@linaro.org \
    --cc=ernesto.mnd.fernandez@gmail.com \
    --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 \
    --cc=willy@infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox