[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210428235702.GE7400@fieldses.org>
Date: Wed, 28 Apr 2021 19:57:02 -0400
From: "J. Bruce Fields" <bfields@...ldses.org>
To: Aurélien Aptel <aaptel@...e.com>
Cc: Namjae Jeon <namjae.jeon@...sung.com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
smfrench@...il.com, senozhatsky@...omium.org, hyc.lee@...il.com,
viro@...iv.linux.org.uk, hch@....de, hch@...radead.org,
ronniesahlberg@...il.com, aurelien.aptel@...il.com,
sandeen@...deen.net, dan.carpenter@...cle.com,
colin.king@...onical.com, rdunlap@...radead.org,
willy@...radead.org
Subject: Re: [PATCH v2 00/10] cifsd: introduce new SMB3 kernel server
On Thu, Apr 29, 2021 at 12:24:17AM +0200, Aurélien Aptel wrote:
> "J. Bruce Fields" <bfields@...ldses.org> writes:
> > I'd rather see multiple patches that were actually functional at each
> > stage: e.g., start with a server that responds to some sort of rpc-level
> > ping but does nothing else, then add basic file IO, etc.
> >
> > I don't know if that's practical.
>
> Although it would certainly be nice I don't think it's realistic to
> expect this kind of retro-logical-rewriting. AFAIK the other new
> fs-related addition (ntfs patchset) is using the same trick of adding
> the Makefile at the end after it was suggested on the mailing list. So
> there's a precedent.
OK, I wondered if that might be the case.
I don't love it, but, fair enough, maybe that's the best compromise.
--b.
Powered by blists - more mailing lists