SMB2 file system - should it be a distinct module

["Steve French" <smfrench@gmail.com>]

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