From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752540AbbLNPeL (ORCPT ); Mon, 14 Dec 2015 10:34:11 -0500 Received: from mail5.windriver.com ([192.103.53.11]:41560 "EHLO mail5.wrs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752029AbbLNPeI (ORCPT ); Mon, 14 Dec 2015 10:34:08 -0500 Date: Mon, 14 Dec 2015 10:34:00 -0500 From: Paul Gortmaker To: Jeff Layton CC: Alexander Viro , , "J. Bruce Fields" , Subject: Re: [PATCH 05/10] fs: make locks.c explicitly non-modular Message-ID: <20151214153359.GI32362@windriver.com> References: <1449955812-10149-1-git-send-email-paul.gortmaker@windriver.com> <1449955812-10149-6-git-send-email-paul.gortmaker@windriver.com> <20151214063105.2b4b624a@tlielax.poochiereds.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20151214063105.2b4b624a@tlielax.poochiereds.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [Re: [PATCH 05/10] fs: make locks.c explicitly non-modular] On 14/12/2015 (Mon 06:31) Jeff Layton wrote: > On Sat, 12 Dec 2015 16:30:07 -0500 > Paul Gortmaker wrote: > > > The Kconfig currently controlling compilation of this code is: > > > > config FILE_LOCKING > > bool "Enable POSIX file locking API" if EXPERT > > > > ...meaning that it currently is not being built as a module by anyone. > > > > Lets remove the couple traces of modularity so that when reading the > > driver there is no doubt it is builtin-only. > > [...] > > Looks fine to me and I doubt we'll see any merge conflicts with > anything I have queued so far. Do you need any of us to pick any of > these up or are you going to be merging them as a set? I was hoping to spread as many of these around as possible so I don't end up with a giant pull request to Linus. There is code out there without a clear maintainership path, so eventually I'll have to send some his way (or via akpm) but the less that end up in that pile, the better IMHO. It looks like the hugetlb init level change upset one of the automated qemu 0-day boot tests, so I need to investigate that next. Paul. -- > > Acked-by: Jeff Layton