All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: David Howells <dhowells@redhat.com>
Cc: dhowells@redhat.com, torvalds@osdl.org, steved@redhat.com,
	trond.myklebust@fys.uio.no, aviro@redhat.com,
	linux-fsdevel@vger.kernel.org, linux-cachefs@redhat.com,
	nfsv4@linux-nfs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/5] Permit NFS superblock sharing [try #2]
Date: Thu, 2 Mar 2006 10:08:38 -0800	[thread overview]
Message-ID: <20060302100838.63bc8741.akpm@osdl.org> (raw)
In-Reply-To: <13560.1141322238@warthog.cambridge.redhat.com>

David Howells <dhowells@redhat.com> wrote:
>
> > nfs-apply-mount-root-dentry-override-to-filesystems:
>  > 3 out of 10 hunks FAILED -- saving rejects to file fs/nfs/inode.c.rej
> 
>  Would it help you if I split the NFS bits out of patch 2 into a separate patch?

I wouldn't worry about splitting patches to make their application easier -
the main thing is to ensure that they're logical units from the
design/implementation POV.  And that the kernel should compile (and
hopefully run) at each stage of the series.

And don't worry about the -mm-only patches - I'll sort them out.  Unless
people are working against functionality which is only in -mm, they should
work against mainline.

But in the case where you're hitting hard on a particular subsystem, the
best tree to work against is that subsystem's tree.  Which is a bit of a
pain if you want to put your feature out to external testers, because then
you need to also make a snapshot of the subsystem tree available as well. 
That's just a cost of doing business, really.  It ends up being extremely
simple if one is using quilt.


WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@osdl.org>
To: David Howells <dhowells@redhat.com>
Cc: aviro@redhat.com, linux-kernel@vger.kernel.org,
	nfsv4@linux-nfs.org, steved@redhat.com, dhowells@redhat.com,
	torvalds@osdl.org, linux-cachefs@redhat.com,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/5] Permit NFS superblock sharing [try #2]
Date: Thu, 2 Mar 2006 10:08:38 -0800	[thread overview]
Message-ID: <20060302100838.63bc8741.akpm@osdl.org> (raw)
In-Reply-To: <13560.1141322238@warthog.cambridge.redhat.com>

David Howells <dhowells@redhat.com> wrote:
>
> > nfs-apply-mount-root-dentry-override-to-filesystems:
>  > 3 out of 10 hunks FAILED -- saving rejects to file fs/nfs/inode.c.rej
> 
>  Would it help you if I split the NFS bits out of patch 2 into a separate patch?

I wouldn't worry about splitting patches to make their application easier -
the main thing is to ensure that they're logical units from the
design/implementation POV.  And that the kernel should compile (and
hopefully run) at each stage of the series.

And don't worry about the -mm-only patches - I'll sort them out.  Unless
people are working against functionality which is only in -mm, they should
work against mainline.

But in the case where you're hitting hard on a particular subsystem, the
best tree to work against is that subsystem's tree.  Which is a bit of a
pain if you want to put your feature out to external testers, because then
you need to also make a snapshot of the subsystem tree available as well. 
That's just a cost of doing business, really.  It ends up being extremely
simple if one is using quilt.

  reply	other threads:[~2006-03-02 18:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-01 17:36 [PATCH 0/5] Permit NFS superblock sharing [try #2] David Howells
2006-03-01 17:36 ` [PATCH 1/5] NFS: Permit filesystem to override root dentry on mount " David Howells
2006-03-01 17:36 ` [PATCH 2/5] NFS: Apply mount root dentry override to filesystems " David Howells
2006-03-01 17:36 ` [PATCH 3/5] NFS: Abstract out namespace initialisation " David Howells
2006-03-01 17:36 ` [PATCH 4/5] NFS: Add dentry materialisation op " David Howells
2006-03-01 17:36 ` [PATCH 5/5] NFS: Unify NFS superblocks per-protocol per-server " David Howells
2006-03-02  0:21 ` [PATCH 0/5] Permit NFS superblock sharing " Andrew Morton
2006-03-02  0:21   ` Andrew Morton
2006-03-02 11:04   ` David Howells
2006-03-02 17:31     ` Andrew Morton
2006-03-02 11:45   ` David Howells
2006-03-02 17:28     ` Andrew Morton
2006-03-02 17:57       ` David Howells
2006-03-02 18:08         ` Andrew Morton [this message]
2006-03-02 18:08           ` Andrew Morton

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=20060302100838.63bc8741.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=aviro@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=linux-cachefs@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nfsv4@linux-nfs.org \
    --cc=steved@redhat.com \
    --cc=torvalds@osdl.org \
    --cc=trond.myklebust@fys.uio.no \
    /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.