[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180523152239.GA2425@infradead.org>
Date: Wed, 23 May 2018 08:22:39 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Kent Overstreet <kent.overstreet@...il.com>
Cc: Christoph Hellwig <hch@...radead.org>,
Matthew Wilcox <willy@...radead.org>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Dave Chinner <dchinner@...hat.com>, darrick.wong@...cle.com,
tytso@....edu, linux-btrfs@...r.kernel.org, clm@...com,
jbacik@...com, viro@...iv.linux.org.uk, peterz@...radead.org
Subject: Re: [PATCH 01/10] mm: pagecache add lock
On Sun, May 20, 2018 at 06:45:24PM -0400, Kent Overstreet wrote:
> >
> > Honestly I think this probably should be in the core. But IFF we move
> > it to the core the existing users of per-fs locks need to be moved
> > over first. E.g. XFS as the very first one, and at least ext4 and f2fs
> > that copied the approach, and probably more if you audit deep enough.
>
> I'm not going to go and redo locking in XFS and ext4 as a prerequisite to
> merging bcachefs. Sorry, but that's a bit crazy.
It isn't crazy at all. In general we expect people to do their fair
share of core work to get their pet feature in. How much is acceptable
is a difficult question and not black and white.
But if you want to grow a critical core structure you better take a stab
at converting existing users. Without that the tradeoff of growing
that core structure is simply not given.
Or to put it in words for this exact feature: unless your new field
is also used by mainstream file systems it is not going to be added.
Powered by blists - more mailing lists