On Apr. 06, 2009, 20:11 +0300, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Mon, Apr 06, 2009 at 11:53:28AM +0300, Benny Halevy wrote: >> On Apr. 06, 2009, 10:27 +0300, Alexander Beregalov <a.beregalov@xxxxxxxxx> wrote: >>> Hi >>> >>> fs/nfsd/nfssvc.c: In function 'set_max_drc': >>> fs/nfsd/nfssvc.c:240: error: 'NFSD_DRC_SIZE_SHIFT' undeclared >>> >>> CONFIG_NFSD_V4 is not set >> Hi Alexander, >> >> Thanks for reporting this! >> >> Andy, Bruce: please see attached 2 patches fixing compile/link errors >> with DRC under !defined(CONFIG_NFSD_V4): >> >> [PATCH 1/2] SQUASHEM: nfsd41: define NFSD_DRC_SIZE_SHIFT in set_max_drc >> [PATCH 2/2] SQUASHME: nfsd41: define nfsd4_set_statp as noop for !CONFIG_NFSD_V4 > > Thanks, applied. > > Committing on top (not squashing) since I'd rather not rewrite history > on a branch I've already sent a pull request for. Cool. Thanks! I wasn't aware that you already sent a pull request already... I got it from mainline now and I'm rebasing and testing the rest of our stuff on top of it. > > (In fact, I'll try to stop rebasing those for-next branches at all this > time around.) I'm with you on that. For 2.6.31, I'd like to send easy-to-swallow patch sets that we can review and agree upon well ahead of the merge window (i.e. start, e.g. with the backchannel stuff shortly after 2.6.30-rc1 is cut) and once we're in agreement on it we can put it in linux-next to be visible to others and get some soak time. This will also be a good time to freeze it, so it won't be rebased, unless something important enough requires that. How does that sound? I think that the same strategy should work for the client side too. Trond what do you think? Benny > > --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
