2012/7/23 Pavel Shilovsky <pshilovsky@xxxxxxxxx>:
> Smb2 will use posix extensions further - we can easily modify the code to
> support it and avoid code dublication. So, I created the patches this way -
> it let us abstract open code logic from protocol. I don't think that having
> several open routines with almost the same code help us to keep the code
> clean and easy to maintain.
> 23.07.2012 17:55 пользователь "Jeff Layton" <jlayton@xxxxxxxxx> написал:
>
>
>>
>> On Wed, 18 Jul 2012 19:48:17 +0400
>> Pavel Shilovsky <pshilovsky@xxxxxxxxx> wrote:
>>
>> > --- a/fs/cifs/file.c
>> > +++ b/fs/cifs/file.c
>> > @@ -385,9 +385,8 @@ int cifs_open(struct inode *inode, struct file
>> > *file)
>> > oplock = 0;
>> >
>> > if (!tcon->broken_posix_open && tcon->unix_ext &&
>> > - (tcon->ses->capabilities & CAP_UNIX) &&
>> > - (CIFS_UNIX_POSIX_PATH_OPS_CAP &
>> > - le64_to_cpu(tcon->fsUnixInfo.Capability))) {
>> > + cap_unix(tcon->ses) && (CIFS_UNIX_POSIX_PATH_OPS_CAP &
>> > + le64_to_cpu(tcon->fsUnixInfo.Capability)))
>> > {
>> > /* can not refresh inode info since size could be stale */
>> > rc = cifs_posix_open(full_path, &inode, inode->i_sb,
>> > cifs_sb->mnt_file_mode /* ignored */,
>>
>> While I'm in general OK with abstracting out things like this with a
>> set of operations, I'm not sure it makes much sense to make things so
>> granular in the name of code-sharing
>>
>> Would it be better for instance, to simply have a different f_ops->open
>> routine for SMB2, and simply check the right bit for CAP_UNIX in each
>> one?
>>
>> --
>> Jeff Layton <jlayton@xxxxxxxxx>
>> --
>> 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
--
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
