Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Trond Myklebust
On Thu, 2008-02-14 at 23:18 +0100, Miklos Szeredi wrote: > I understand perfectly that this is what you want to do. And I'm > saying that the following code snippet should do exactly the same, > without having to add a new syscall: > > char tmpbuf[64]; > sprintf(tmpbuf,

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Miklos Szeredi
> On Thu, Feb 14, 2008 at 9:31 AM, Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > > I deliberately not used the MS_* flags, which is currently a messy mix > > of things with totally different meanings. > > > > Does this solve all the issues? > > We should add a size parameter either in the

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Miklos Szeredi
> On Thu, 2008-02-14 at 18:39 +0100, Miklos Szeredi wrote: > > > > And I'm not against doing it with the "at*" variants, as Trond > > > > suggested. > > > > > > If you're going to change the syscall, then you should ensure that it > > > solves _all_ the problems that are known at this time.

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Trond Myklebust
On Thu, 2008-02-14 at 18:39 +0100, Miklos Szeredi wrote: > > > And I'm not against doing it with the "at*" variants, as Trond > > > suggested. > > > > If you're going to change the syscall, then you should ensure that it > > solves _all_ the problems that are known at this time. Ignoring the > >

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Paul Menage
On Thu, Feb 14, 2008 at 9:31 AM, Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > I deliberately not used the MS_* flags, which is currently a messy mix > of things with totally different meanings. > > Does this solve all the issues? We should add a size parameter either in the mount_params or as

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Miklos Szeredi
> > And I'm not against doing it with the "at*" variants, as Trond > > suggested. > > If you're going to change the syscall, then you should ensure that it > solves _all_ the problems that are known at this time. Ignoring the > automounter issue is just going to force us to redo the syscall in a

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Miklos Szeredi
> > Maybe instead of messing with masks, it's better to introduce a > > get_flags() or a more general mount_stat() operation, and let > > userspace deal with setting and clearing flags, just as we do for > > stat/chmod? > > > > So we'd have > > > > mount_stat(path, stat); > >

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Trond Myklebust
On Thu, 2008-02-14 at 17:03 +0100, Miklos Szeredi wrote: > And I'm not against doing it with the "at*" variants, as Trond > suggested. If you're going to change the syscall, then you should ensure that it solves _all_ the problems that are known at this time. Ignoring the automounter issue is

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Paul Menage
On Thu, Feb 14, 2008 at 8:03 AM, Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > The "flags" argument could be the same as for regular mount, and > > contain the mnt_flags - so the extra argument could maybe usefully be > > a "mnt_flags_mask", to indicate which flags we actually care about > >

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Miklos Szeredi
> On Thu, Feb 14, 2008 at 12:30 AM, Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > For recursive bind mounts, only the root of the tree being bound > > > inherits the per-mount flags from the mount() arguments; sub-mounts > > > inherit their per-mount flags from the source tree as usual. > > >

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Paul Menage
[ cc: linux-fsdevel ] On Thu, Feb 14, 2008 at 7:22 AM, Paul Menage <[EMAIL PROTECTED]> wrote: > On Wed, Feb 13, 2008 at 10:02 PM, Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > > > I think this concept is reasonable, but I don't think MS_BIND_FLAGS > > is a descriptive name for this flag.

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Paul Menage
On Wed, Feb 13, 2008 at 10:02 PM, Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > I think this concept is reasonable, but I don't think MS_BIND_FLAGS > is a descriptive name for this flag. MS_EXPLICIT_FLAGS might be better > but still isn't optimal. > MS_BIND_FLAGS_OVERRIDE ? Paul -- To

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Paul Menage
On Thu, Feb 14, 2008 at 12:30 AM, Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > For recursive bind mounts, only the root of the tree being bound > > inherits the per-mount flags from the mount() arguments; sub-mounts > > inherit their per-mount flags from the source tree as usual. > > This is

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Trond Myklebust
On Thu, 2008-02-14 at 09:30 +0100, Miklos Szeredi wrote: > And this is where we usually conclude, that a new userspace mount API > is long overdue. So for starters, how about a new syscall for bind > mounts: > > int mount_bind(const char *src, const char *dst, unsigned flags, >

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Miklos Szeredi
Please always CC linux-fsdevel on VFS patches! > From: Paul Menage <[EMAIL PROTECTED]> > > Add a new mount() flag, MS_BIND_FLAGS. > > MS_BIND_FLAGS indicates that a bind mount should take its per-mount flags > from the arguments passed to mount() rather than from the source > mountpoint. This

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Miklos Szeredi
Please always CC linux-fsdevel on VFS patches! From: Paul Menage [EMAIL PROTECTED] Add a new mount() flag, MS_BIND_FLAGS. MS_BIND_FLAGS indicates that a bind mount should take its per-mount flags from the arguments passed to mount() rather than from the source mountpoint. This is

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Trond Myklebust
On Thu, 2008-02-14 at 09:30 +0100, Miklos Szeredi wrote: And this is where we usually conclude, that a new userspace mount API is long overdue. So for starters, how about a new syscall for bind mounts: int mount_bind(const char *src, const char *dst, unsigned flags,

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Paul Menage
On Thu, Feb 14, 2008 at 12:30 AM, Miklos Szeredi [EMAIL PROTECTED] wrote: For recursive bind mounts, only the root of the tree being bound inherits the per-mount flags from the mount() arguments; sub-mounts inherit their per-mount flags from the source tree as usual. This is rather

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Paul Menage
On Wed, Feb 13, 2008 at 10:02 PM, Christoph Hellwig [EMAIL PROTECTED] wrote: I think this concept is reasonable, but I don't think MS_BIND_FLAGS is a descriptive name for this flag. MS_EXPLICIT_FLAGS might be better but still isn't optimal. MS_BIND_FLAGS_OVERRIDE ? Paul -- To

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Paul Menage
[ cc: linux-fsdevel ] On Thu, Feb 14, 2008 at 7:22 AM, Paul Menage [EMAIL PROTECTED] wrote: On Wed, Feb 13, 2008 at 10:02 PM, Christoph Hellwig [EMAIL PROTECTED] wrote: I think this concept is reasonable, but I don't think MS_BIND_FLAGS is a descriptive name for this flag.

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Miklos Szeredi
On Thu, Feb 14, 2008 at 12:30 AM, Miklos Szeredi [EMAIL PROTECTED] wrote: For recursive bind mounts, only the root of the tree being bound inherits the per-mount flags from the mount() arguments; sub-mounts inherit their per-mount flags from the source tree as usual. This is

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Paul Menage
On Thu, Feb 14, 2008 at 8:03 AM, Miklos Szeredi [EMAIL PROTECTED] wrote: The flags argument could be the same as for regular mount, and contain the mnt_flags - so the extra argument could maybe usefully be a mnt_flags_mask, to indicate which flags we actually care about overriding.

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Trond Myklebust
On Thu, 2008-02-14 at 17:03 +0100, Miklos Szeredi wrote: And I'm not against doing it with the at* variants, as Trond suggested. If you're going to change the syscall, then you should ensure that it solves _all_ the problems that are known at this time. Ignoring the automounter issue is just

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Miklos Szeredi
Maybe instead of messing with masks, it's better to introduce a get_flags() or a more general mount_stat() operation, and let userspace deal with setting and clearing flags, just as we do for stat/chmod? So we'd have mount_stat(path, stat); mount_bind(from, to, flags);

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Paul Menage
On Thu, Feb 14, 2008 at 9:31 AM, Miklos Szeredi [EMAIL PROTECTED] wrote: I deliberately not used the MS_* flags, which is currently a messy mix of things with totally different meanings. Does this solve all the issues? We should add a size parameter either in the mount_params or as a

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Trond Myklebust
On Thu, 2008-02-14 at 18:39 +0100, Miklos Szeredi wrote: And I'm not against doing it with the at* variants, as Trond suggested. If you're going to change the syscall, then you should ensure that it solves _all_ the problems that are known at this time. Ignoring the automounter

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Miklos Szeredi
On Thu, 2008-02-14 at 18:39 +0100, Miklos Szeredi wrote: And I'm not against doing it with the at* variants, as Trond suggested. If you're going to change the syscall, then you should ensure that it solves _all_ the problems that are known at this time. Ignoring the

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Miklos Szeredi
On Thu, Feb 14, 2008 at 9:31 AM, Miklos Szeredi [EMAIL PROTECTED] wrote: I deliberately not used the MS_* flags, which is currently a messy mix of things with totally different meanings. Does this solve all the issues? We should add a size parameter either in the mount_params or

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-14 Thread Trond Myklebust
On Thu, 2008-02-14 at 23:18 +0100, Miklos Szeredi wrote: I understand perfectly that this is what you want to do. And I'm saying that the following code snippet should do exactly the same, without having to add a new syscall: char tmpbuf[64]; sprintf(tmpbuf, /proc/self/fd/%i,

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-13 Thread Christoph Hellwig
On Tue, Feb 12, 2008 at 09:45:15PM -0800, Paul Menage wrote: > From: Paul Menage <[EMAIL PROTECTED]> > > Add a new mount() flag, MS_BIND_FLAGS. > > MS_BIND_FLAGS indicates that a bind mount should take its per-mount flags > from the arguments passed to mount() rather than from the source >

Re: [PATCH] Add MS_BIND_FLAGS mount flag

2008-02-13 Thread Christoph Hellwig
On Tue, Feb 12, 2008 at 09:45:15PM -0800, Paul Menage wrote: From: Paul Menage [EMAIL PROTECTED] Add a new mount() flag, MS_BIND_FLAGS. MS_BIND_FLAGS indicates that a bind mount should take its per-mount flags from the arguments passed to mount() rather than from the source mountpoint.

[PATCH] Add MS_BIND_FLAGS mount flag

2008-02-12 Thread Paul Menage
From: Paul Menage <[EMAIL PROTECTED]> Add a new mount() flag, MS_BIND_FLAGS. MS_BIND_FLAGS indicates that a bind mount should take its per-mount flags from the arguments passed to mount() rather than from the source mountpoint. This flag allows you to create a bind mount with the desired

[PATCH] Add MS_BIND_FLAGS mount flag

2008-02-12 Thread Paul Menage
From: Paul Menage [EMAIL PROTECTED] Add a new mount() flag, MS_BIND_FLAGS. MS_BIND_FLAGS indicates that a bind mount should take its per-mount flags from the arguments passed to mount() rather than from the source mountpoint. This flag allows you to create a bind mount with the desired