Received-SPF: pass (google.com: domain of linux-kernel+bounces-52578-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Mon, 5 Feb 2024 13:10:28 +0100
From: Christian Brauner <brauner@kernel.org>
To: Jeff Layton <jlayton@kernel.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>, 
	Chuck Lever <chuck.lever@oracle.com>, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, 
	kernel test robot <lkp@intel.com>
Subject: Re: [PATCH] filelock: add stubs for new functions when
 CONFIG_FILE_LOCKING=n
Message-ID: <20240205-prall-herde-c413a323b54c@brauner>
References: <20240204-flsplit3-v1-1-9820c7d9ce16@kernel.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20240204-flsplit3-v1-1-9820c7d9ce16@kernel.org>

> Another thought too: "locks_" as a prefix is awfully generic. Might it be
> better to rename these new functions with a "filelock_" prefix instead?
> That would better distinguish to the casual reader that this is dealing
> with a file_lock object. I'm happy to respin the set if that's the
> consensus.

If it's just a rename then just point me to a branch I can pull. I don't
think it's worth resending just because you effectively did some variant
of s/lock_*/filelock_*/g

In any case, folded this one.