2012/7/23 Pavel Shilovsky <[email protected]>: > 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" <[email protected]> написал: > > >> >> On Wed, 18 Jul 2012 19:48:17 +0400 >> Pavel Shilovsky <[email protected]> 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 <[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
-- Best regards, Pavel Shilovsky. -- 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
