Re: [linux-cifs-client] review 5, was Re: projected date for mount.cifs to support DFS junction points

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2/15/08, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> On Fri, Feb 15, 2008 at 07:37:35PM +0300, Q (Igor Mammedov) wrote:
>  > Here is what I've done the last weekend.
>  > Attached:
>  >  fixed patch [5/5] (0001-DFS-patch-that-connects-inode-with-dfs-handling-ops.patch).
Not merged yet.

>  >  fixed mixed case in struct member 0002-Fixed-mixed-case-name-in-structure-dfs_info3_param.patch)

Now merged into cifs-2.6.git

> The second one is trivially correct and should be pushed to Linus asap
>  as small cleanup.  Patch 1 is not exactly what I had in mind, I was
>  thinking about factoring out the common bits of cifs-cifs_get_inode_info
>  and cifs-cifs_get_inode_info_unix to avoid having all the logic to
>  set the various options twice.  I've attached two quick and untested
>  patches showing what I mean.  I think in this case having the ifdef
>  for that two line statement setting the inode operations here is fine.
I reviewed and merged into cifs-2.6.git one of the two patches from
Christoph (the cifs_set_ops one), but wanted to look more carefully at
the other (cifs_get_info_remote) to make sure that buf was being freed
in the cifs_get_inode_info path (otherwise it is fine).

>  But thinking about it I'm not even sure if it's good idea to make
>  dfs support conditional.  Any reason it can't just be included
>  unconditionally?
It would make the code slightly smaller (perhaps useful someday for
OLPC or embedded) and removes a piece of code that is not needed in
all home networks (although DFS is useful even to some of these).  I
lean toward removing the ifdef when it has made it through one or two
more release cycles and is no longer experimental.   SInce there are a
few experimental features (Kerberos and DFS) that are broadly useful -
but not all users need both, I don't mind keeping the configure for
each different for the short term but don't have a strong opinion on
this.

-- 
Thanks,

Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux