All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [git pull] vfs, part 1
Date: Wed, 3 Oct 2012 03:48:11 +0100	[thread overview]
Message-ID: <20121003024811.GO13973@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+55aFwot+bbm_L93kqCfLDEuQUSdWK=cRdDG-W7=O4zEh96RQ@mail.gmail.com>

On Tue, Oct 02, 2012 at 07:31:58PM -0700, Linus Torvalds wrote:
> On Tue, Oct 2, 2012 at 6:39 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >         This is *not* all; fs/dcache.c bits will go separately, for one
> > thing - that's just the first pile.  Please, pull from the usual place -
> 
> Al, *please* describe what is going on. Your description is negative
> (what *doesn't* happen in this pull) and does not at all describe what
> is going on.

Umm...  OK, but it won't be particulary pretty:
	* big one - consolidation of descriptor-related logics; almost all
of that is moved to fs/file.c (BTW, I'm seriously tempted to rename the
result to fd.c.  As it is, we have a situation when file_table.c is about
handling of struct file and file.c is about handling of descriptor tables;
the reasons are historical - file_table.c used to be about a static array
of struct file we used to have way back).   A lot of stray ends got cleaned
up and converted to saner primitives, disgusting mess in android/binder.c
is still disgusting, but at least doesn't poke so much in descriptor table
guts anymore.  A bunch of relatively minor races got fixed in process,
plus an ext4 struct file leak.
	* related thing - fget_light() partially unuglified; see fdget()
in there (and yes, it generates the code as good as we used to have).
	* also related - bits of Cyrill's procfs stuff that got entangled
into that work; _not_ all of it, just the initial move to fs/proc/fd.c
and switch of fdinfo to seq_file.
	* Alex's fs/coredump.c spiltoff - the same story, had been easier to
take that commit than mess with conflicts.  The rest is a separate pile, this
was just a mechanical code movement.
	* a few misc patches all over the place.  Not all for this cycle,
there'll be more (and quite a few currently sit in akpm's tree).

  reply	other threads:[~2012-10-03  2:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-03  1:39 [git pull] vfs, part 1 Al Viro
2012-10-03  2:31 ` Linus Torvalds
2012-10-03  2:48   ` Al Viro [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-04-14  1:42 [git pull] vfs " Al Viro
2010-10-26 23:17 [git pull] vfs, " Al Viro

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=20121003024811.GO13973@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.