On Tue, Mar 8, 2011 at 6:15 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Tue, 8 Mar 2011 06:29:15 -0500 > Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > >> Sorry Steve, >> >> first you need to explain why a totall different protocol is better >> suited stuffed into the fucking mess than the cifs module than a clean >> start. Second you absolutely need to post patches for review before >> commiting them. While others are cleaning up the mess you >> singlehandedly are making it worse constantly. It can't go on that way >> much longer. >> > > SMB2 servers are also generally CIFS servers. There is a mechanism to > autonegotiate when talking to a sever to decide which protocol to use. > Making a completely separate fstype and module however will mean that > we can't effectively use that mechanism. Userspace will have to decide > "smb2" or "cifs" at mount time and tough luck if you get it wrong. > > I'd like to avoid the same mistake made with "nfs" vs. "nfs4" fstypes. > That was a real pain to clean up after the fact and still isn't 100% > the way we'd really like (there's still a nfs4 fstype, for instance). > > I think putting it in the same module and sharing the fstype is the > right thing to do. Much of the code between CIFS and SMB2 can be shared > and there's little value in putting that into a separate module. I > think we'll be far better served by abstracting out the existing code > where we can. > > That said, I'm also not very happy with the how the SMB2 merge is > going. A lot of this code seems to be getting merged without any review > at all on the list. I really don't care how big they are -- I'd like to > see patchsets mailed out as anyone else would. That is more practical now. With the protocol definitions, error codes, and the added fields in the global structures, it is easier to talk about and incrementally review. I will be putting the subsequent patches on list. Next steps in the conversion: - transport handling - smb2 demultiplexing (following up on some of your ideas from connectathon) - finish up of the mount code (which presumably will look more like cifs now than the earlier smb2 prototype) It will be much easier to review when enough code is converted to allow mount and testing. In this first set of code, I tried to balance which ones are practical to rereview with which ones are not. I tried to send out the changes to structures which affect cifs mounts in particular. But it was harder for a few of the big early conversions of files from smb2.git to cifs-2.6.git For example, rereviewing the two largest pieces (the list of error codes, and the list of header definitions) would be hard - they are too big for email and come from the spec. -- Thanks, Steve -- 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
