[lkml]   [2005]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] cifs: handle termination of cifs oplockd kernel thread
Christoph Hellwig wrote:

>should export it in /proc/<pid>/mounts, which is
>an ASCII interface and any half-sane parser does not depend on the width
>of the field in the kernel.
>Can we please get rid of the broken ioctl now so it doesn't become part
>of the ABI and you'll add the trivial output to /proc/<pid>/mounts?
OK - why don't we just add this (ie the ioctl removal) to the patch

[PATCH] unprivileged mount/umount

of Miklos et al, since that removes the need to modify showmounts (and
avoids any name collision/confusion
with the existing meaning of the mount option "uid" ie as the default
uid to use for files on the system when
mounting to servers which can not return inode owners as uids).

On another topic relating to ioctls, various people have suggested
adding an ioctl to add a table to optionally map file owner (uid / gid
mapping tables) on remote filesystems. Although this is easy enough to
do for the case of CIFS, this seems like a function (loading the table)
that could be done via /proc or perhaps even sysfs. Is there are
precedent for doing this on Linux? Googling I see various examples where
NFS client on other platforms (not Linux) have done something vaguely
similar. NFSv4 uses an upcall for this (although they are mapping
slightly differently since they now receive a fully qualified username
and have to map this to a loca uid, rather than getting a remote uid to
local uid as earlier nfs did). The general issue is that when mounting
to multiple Unix/Linux servers (especially in different domains), unlike
in Windows (or perhaps MacOS), similar users are defined with different
uids, and there are cases where mapping uids/gids or ranges of uids/gids
from that returned from the server would be helpful. The mapping table
would have to hang off the tree connection or the SMB session for the
case of CIFS but I would rather not use an ioctl to load it, yet if the
table ever got big, I would prefer not to use /proc either. Is there a
recommended approach.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-05-11 20:27    [W:0.082 / U:6.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site