Linux CIFS filesystem development
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Cc: Pavel Shilovsky
	<piastryyy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: smb2 work status
Date: Tue, 19 Jul 2011 07:24:33 -0400	[thread overview]
Message-ID: <20110719072433.7f9c1cd2@corrin.poochiereds.net> (raw)
In-Reply-To: <20110718154730.GA5822-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>

On Mon, 18 Jul 2011 11:47:30 -0400
Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:

> On Mon, Jul 18, 2011 at 07:45:01PM +0400, Pavel Shilovsky wrote:
> > If I understand you right, you mean to separate inode and file
> > operations for smb2 into a different structures, set them once with
> > ifdefs in cifs_set_ops() and keep them in smb2inode.c and smb2file.c
> > files.
> 
> That's the idea.  You'll really have to prototype it to check if it
> works out nicely.  If we end up duplicating too much it might not
> be feasible, but fro ma quick look it should be much better.
> 

Agreed. Once you mount, you know what protocol version you're using.
There's little value in continually checking that.

Another idea to consider would be to keep the same set of VFS ops, and
abstract out the lower level set of protocol operations. This is the
model that NFS uses for NFSv2 and 3. v4 is a bit different but it
does use the same file and inode ops for some things. See, for example,
nfs_v3_clientops.

Even if you do take Christoph's suggestion, I think there is value in
abstracting out the protocol operations as well. Better organization
like this will make the code less of a pain to maintain over the long
term.

There are also some things in this set that really ought to be
encapsulated into accessor routines. For example:

+       /* Don't want to modify the buffer as a side effect of this call. */
+       if (server->is_smb2 == false)
+               smb_buffer->smb_buf_length = cpu_to_be32(smb_buf_length);
+#ifdef CONFIG_CIFS_SMB2
+       else
+               smb2_buffer->smb2_buf_length = cpu_to_be32(smb_buf_length);
+#endif


-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

  parent reply	other threads:[~2011-07-19 11:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-12  6:29 smb2 work status Pavel Shilovsky
     [not found] ` <CAKywueQqyi6ynwoAv6Q3GzbxYJSOv7k229N3NA_y05kguqA+DQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-07-16  9:29   ` Pavel Shilovsky
     [not found]     ` <CAKywueRiuj=DrumdGMvdWX6ih8PVz4L0BL7G=LNL6CO+cEfmTQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-07-16 19:28       ` Christoph Hellwig
     [not found]         ` <20110716192811.GE26925-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2011-07-18 15:45           ` Pavel Shilovsky
     [not found]             ` <CAKywueSP7p3pja6FociCPXDtcSuChDdHw1JqCwxyhnqMuP5ahg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-07-18 15:47               ` Christoph Hellwig
     [not found]                 ` <20110718154730.GA5822-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2011-07-19 11:24                   ` Jeff Layton [this message]
2011-07-20 14:19                   ` Pavel Shilovsky
2011-07-24 14:56       ` Pavel Shilovsky
     [not found]         ` <CAKywueTDhS_FHtssdVbSrBiPksngYsmotU69u9S1QELnm9Vh+w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-07-26 19:41           ` Pavel Shilovsky
     [not found]             ` <CAKywueQ2B6R7EzB2t4WDfR15Ot-x823zBzy9nQwRwZSxdpco1Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-08-03 20:20               ` Pavel Shilovsky
  -- strict thread matches above, loose matches on Subject: below --
2011-06-02 21:10 Pavel Shilovsky
     [not found] ` <BANLkTik5T2aY4V-Kp-AePZYUR+KgKCyNCA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-02 21:17   ` Steve French
     [not found]     ` <BANLkTi=NEJ2smKXM_irraWnN6gWpzGbTvA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-07 18:07       ` Pavel Shilovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110719072433.7f9c1cd2@corrin.poochiereds.net \
    --to=jlayton-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=piastryyy-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox