2010/10/12 Jeff Layton <jlayton@xxxxxxxxx>: > In interrupt context, we'll read the header down to the MID and look up > the request in a table (similar to how we do today in CIFS). For sync > requests, we'll wake up the waiting thread which would copy the header > info read so far into the buffer, and read the rest of the reply off > the socket. The smb layer will provide functions that the upper layers > can use to read in the rest of the reply (not 100% sure of the best way > to do that yet). So, CIFS and SMB2 have the different headers and the different locations of MID fileld. Do you mean that sk_data_ready will be different for them too? Or it will be a common part that reads protocol id from the socket and then move the handling of another part (before MID - included) to a protocol specific funсtion? > async requests will require the caller to set up a callback function to > handle the reply. That callback function will be queued to the > workqueue. It'll need to read in the rest of the reply off the socket > and then process the result. > > I think this is a cleaner and more efficient approach than having more > threads. I found the example of using sk_* functions in Ceph filesystem code - is it what you mean? (http://git.kernel.org/?p=linux/kernel/git/sfrench/cifs-2.6.git;a=blob;f=fs/ceph/messenger.c;h=2502d76fcec175ddb8500bcd1863c52add1208e5;hb=d7c86ff8cd00abc730fe5d031f43dc9138b6324e#l186) > Thanks for looking. I'm trying to make sure I have the design at least > somewhat finalized before I start coding. No problem. I think that transport layer isn't only the place that we can pick up to do i common between CIFS and SMB2. For example, many file and inode operations is almost the same and different in protocol message structures. > I may move it to the samba wiki once it's a bit more finalized. I'm not > a huge fan of google docs ;). Samba wiki is ok too. -- 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
