linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Benny Halevy <bhalevy@panasas.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org, Andy Adamson <andros@netapp.com>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	NFS list <linux-nfs@vger.kernel.org>,
	pNFS Mailing List <pnfs@linux-nfs.org>
Subject: Re: linux-next: nfs tree build failures
Date: Mon, 06 Apr 2009 16:34:25 -0700	[thread overview]
Message-ID: <1239060865.6196.2.camel@heimdal.trondhjem.org> (raw)
In-Reply-To: <49D9B2B9.5010401@panasas.com>

On Mon, 2009-04-06 at 10:43 +0300, Benny Halevy wrote:
> On Apr. 06, 2009, 9:29 +0300, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Trond,
> > 
> > Today's linux-next build (powerpc ppc44x_config) failed like this:
> > 
> > fs/nfs/client.c: In function 'nfs_match_client':
> > fs/nfs/client.c:444: error: 'struct nfs_client' has no member named 'cl_minorversion'
> > 
> > Caused by commit 10d5a514705f0687cfbb6a080c3562b857e340fe ("nfs41: Use
> > mount minorversion option").  The existence of cl_minorversion is
> > controlled by CONFIG_NFS_V4 but the reference is not.
> 
> 
> Stephan,
> 
> First, thanks! I apologize for introducing this.
> This was caused by a late fix to Trond's review comment which
> apparently was under-tested, as you mentioned.
> 
> > 
> > I added the small patch below for today.
> 
> Based on Trond's review comment:
> http://linux-nfs.org/pipermail/pnfs/2009-March/006938.html
> 
> We'd actually want to keep cl_minorversion's usage in the clear
> and rather move its definition out of the #ifdef.
> 
> Please see PATCH 1/3 in reply to this message.
> 
> > 
> > The same build gets this warning as well:
> > 
> > fs/nfs/client.c:554: warning: 'nfs4_session_set_rwsize' defined but not used
> 
> This one needs to go under CONFIG_NFS_V4.
> See PATCH 2/2
> 
> > 
> > and then fails like this:
> > 
> > fs/built-in.o: In function `nfs_readpage_result_full':
> > read.c:(.text+0x70d24): undefined reference to `nfs4_restart_rpc'
> > fs/built-in.o: In function `nfs_readpage_result_partial':
> > read.c:(.text+0x70e3c): undefined reference to `nfs4_restart_rpc'
> > fs/built-in.o: In function `nfs_async_unlink_done':
> > unlink.c:(.text+0x71af0): undefined reference to `nfs4_restart_rpc'
> > fs/built-in.o: In function `nfs_writeback_done':
> > (.text+0x72c00): undefined reference to `nfs4_restart_rpc'
> > 
> > Caused by commit c105a9f16f11aaa9fcb9f75f8342b89c5d9665cf ("nfs41: use
> > rpc prepare call state for session reset") which I have reverted for
> > today.
> 
> See PATCH 3/3 that inlines nfs4_restart_rpc's definition.
> 
> Benny

All squashed into the relevant original patches.

> > 
> > Trond, is all this NFS v4.1 stuff that turned up yesterday really 2.6.30
> > material?  If not, it should be removed from linux-next until after
> > 2.6.30-rc1 is released.  (and clearly better tested ...)
> > 
> > Bruce, I guess the same question applies to the nfsd tree as well.

This is code that isn't supposed to significantly affect the existing
NFS tree unless CONFIG_NFS_V4_1 is set. Since the corresponding NFSd
code has been merged into 2.6.30, it would be nice to have the client
code too so that people can start testing, and so that development can
continue in the mainline tree instead of in the smoky backrooms of the
linux-nfs.org git trees.

Cheers
  Trond

      parent reply	other threads:[~2009-04-06 23:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-06  6:29 linux-next: nfs tree build failures Stephen Rothwell
2009-04-06  7:43 ` Benny Halevy
2009-04-06  7:49   ` [PATCH 1/3] SQUASHME: nfs41: always define nfs_client.cl_minorversion Benny Halevy
     [not found]   ` <49D9B2B9.5010401-C4P08NqkoRlBDgjK7y7TUQ@public.gmane.org>
2009-04-06  7:49     ` [PATCH 2/3] SQUASHME: nfs41: move nfs4_session_set_rwsize into CONFIG_NFS_V4 Benny Halevy
2009-04-06  7:50     ` [PATCH 3/3] SQUASHME: inline nfs4_restart_rpc Benny Halevy
2009-04-06 23:34   ` Trond Myklebust [this message]

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=1239060865.6196.2.camel@heimdal.trondhjem.org \
    --to=trond.myklebust@fys.uio.no \
    --cc=andros@netapp.com \
    --cc=bfields@fieldses.org \
    --cc=bhalevy@panasas.com \
    --cc=linux-next@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=pnfs@linux-nfs.org \
    --cc=sfr@canb.auug.org.au \
    /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).