linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Jeff Layton <jlayton@poochiereds.net>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	<linux-kernel@vger.kernel.org>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	<linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 05/10] fs: make locks.c explicitly non-modular
Date: Mon, 14 Dec 2015 10:34:00 -0500	[thread overview]
Message-ID: <20151214153359.GI32362@windriver.com> (raw)
In-Reply-To: <20151214063105.2b4b624a@tlielax.poochiereds.net>

[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 <paul.gortmaker@windriver.com> 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 <jlayton@poochiereds.net>

  reply	other threads:[~2015-12-14 15:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-12 21:30 [PATCH 00/10] fs: don't use module_init in non-modular code Paul Gortmaker
2015-12-12 21:30 ` [PATCH 03/10] fs: make fcntl.c explicitly non-modular Paul Gortmaker
2015-12-12 21:30 ` [PATCH 04/10] fs: make filesystems.c " Paul Gortmaker
2015-12-12 21:30 ` [PATCH 05/10] fs: make locks.c " Paul Gortmaker
2015-12-14 11:31   ` Jeff Layton
2015-12-14 15:34     ` Paul Gortmaker [this message]
2015-12-12 21:30 ` [PATCH 06/10] fs: make direct-io.c " Paul Gortmaker
2015-12-12 21:30 ` [PATCH 08/10] fs: make binfmt_elf.c " Paul Gortmaker
2015-12-12 21:30 ` [PATCH 09/10] fs: make hugetlbfs/inode.c " Paul Gortmaker
2015-12-14 16:14   ` Paul Gortmaker
2015-12-14 20:41     ` [PATCH v2] hugetlb: make mm and fs code " Paul Gortmaker
2015-12-12 21:30 ` [PATCH 10/10] fs: make quota/dquot.c " Paul Gortmaker
2015-12-14 11:05   ` Jan Kara

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=20151214153359.GI32362@windriver.com \
    --to=paul.gortmaker@windriver.com \
    --cc=bfields@fieldses.org \
    --cc=jlayton@poochiereds.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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;
as well as URLs for NNTP newsgroup(s).