On Fri, 20 Jan 2012 12:35:11 +0400 Pavel Shilovsky <piastry@xxxxxxxxxxx> wrote: > Signed-off-by: Pavel Shilovsky <piastry@xxxxxxxxxxx> > --- > fs/cifs/Makefile | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/fs/cifs/Makefile b/fs/cifs/Makefile > index 005d524..0f72f14 100644 > --- a/fs/cifs/Makefile > +++ b/fs/cifs/Makefile > @@ -15,3 +15,7 @@ cifs-$(CONFIG_CIFS_UPCALL) += cifs_spnego.o > cifs-$(CONFIG_CIFS_DFS_UPCALL) += dns_resolve.o cifs_dfs_ref.o > > cifs-$(CONFIG_CIFS_FSCACHE) += fscache.o cache.o > + > +cifs-$(CONFIG_CIFS_SMB2) += smb2pdu.o smb2misc.o smb2transport.o maperror.o \ > + smb2inode.o smb2dir.o smb2file.o smb2readdir.o \ > + smb2link.o I'm a bit concerned about the order of the patches. The idea here seems to be: "merge all of the code needed to support SMB2 with it disabled, and then flip a switch to turn it all on". Experience has shown that that strategy of merging large scale changes tends to be problematic. Bugs that creep in, but because the "switch" is in the last few patches we can't bisect to narrow down the cause. What might be better is to move the last few patches earlier in the series. That would allow someone to mount a SMB2 filesystem, even if some things on it don't actually work yet. If, for instance, an oops creeps in and we're not sure what's causing it, we could bisect down to an earlier patch and narrow down the amount of changes that we'll need to look at. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
