2012/1/23 Jeff Layton <jlayton@xxxxxxxxxx>: > 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> I agree with you. The only reason why 48,49 and 50 patches are going at last is that: they have been already merged in mainline before but then reverted back here http://comments.gmane.org/gmane.linux.kernel.cifs/3315. If nobody objects, I suggest them to be merged after the 01/50 patch (that doesn't not include any CONFIG_CIFS_SMB2 ifdefs). -- Best regards, Pavel Shilovsky. -- 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
