On Tue, Apr 07, 2009 at 09:53:38PM +0300, Benny Halevy wrote: > 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, Note that it's OK to rebase things in -next; so it doesn't have to be frozen till it goes into one of our trees. (And I've tried once or twice to maintain the discpline of not rebasing stuff in my tree and have failed.... I'll make a better effort this time.) > unless something > important enough requires that. How does that sound? Sounds fine. If you send in things as they're ready, I'll try to turn them around a little faster (within a few days or a week anyway). --b. > 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-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
