On Fri, 22 Apr 2011 14:33:08 +0400 Pavel Shilovsky <[email protected]> wrote:
> 2011/4/15 Steve French <[email protected]>: > > I think nested mid structures (around a base of common mid fields) > > like the above is going to be the easiest way to handle the differences. > > > > I don't understand your PROTOCOL_ID #define though - we > > identify smb2 vs. cifs via a bool in the tcp server info struct, > > and presumably if we don't have access to the tcp server > > info struct we would have to add a field in the base mid > > (struct mid_q_entry) that indicates smb2 vs. cifs.. > > I've just thought about to share tcp_server_info struct between > different protocol connections. So, we can use cifs and smb2 > connection on the same server and don't keep two socket connections. > What do you think about to store protocol_id in ses_info rather that > tcp_server_info? > I don't think that's actually allowed by the protocol. Once a socket has had a NEGOTIATE done on it, you can't go back and re-do another one. -- Jeff Layton <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
