During SambaXP conference last week, one of the Samba 4 developers talked about the work doing a prototype server for SMB2 protocol which got me thinking about the client side of this again.
As some background Windows Vista includes support for a new network file system protocol, SMB2 (which is the default used on mount ie NET USE or equivalent). It is somewhat related to CIFS, although the header format is bigger, better aligned and more of the operations are handle based (rather than path based). SMB2 is somewhat better than CIFS in a few ways (although we would have to add Unix Extensions as we have with CIFS to make it ideal for Linux). Now that we (Samba team) understand enough about it to implement prototypes (there is a prototype server in Samba 4, and a userspace client library for testing), we need to decide whether the kernel implementation of SMB2 client should be a distinct module or just part of the cifs.ko module. SMB2 (the protocol) is smaller than cifs, and obviously no backlevel dialects to support (only slightly more than 12 different SMB2 network commands would have to be used, although two have a couple of different information levels each that the client would need to send). My guess is that less than 1/3 of the cifs module would overlap - but that overlap is enough that it would be easier to do smb2 as part of cifs (although it would make the cifs module somewhat larger). During protocol negotiation (SMB Negotiate Protocol) SMB2 is listed as a different dialect - if the server accepts SMB2 dialect then subsequent commands begin with 0xFE instead of 0xFF and the header fields are bigger and better aligned. Any idea which would be preferred (smb2 support as part of cifs, or as a distinct smb2.ko module)? -- Thanks, Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
