mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: viro@parcelfarce.linux.theplanet.co.uk
To: Mike Waychison <michael.waychison@sun.com>
Cc: David Howells <dhowells@warthog.cambridge.redhat.com>,
	David Howells <dhowells@redhat.com>,
	Linus Torvalds <torvalds@transmeta.com>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] VFS autmounter support v2
Date: Thu, 19 Jun 2003 16:34:53 +0100	[thread overview]
Message-ID: <20030619153453.GG6754@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <3EF1D326.4040109@sun.com>

On Thu, Jun 19, 2003 at 11:13:42AM -0400, Mike Waychison wrote:
 
> Introducing special trap vfsmounts w/o super_blocks means we can no 
> longer have arbitrary actions on those traps.  AFS wants to define what 
> happens in kernelspace, autofs wants to define it in userspace.  Last I 
> checked, vfsmount doesn't have an ops structure.

It would have send an event over attached opened file.  Attached at
creation time.
 
> This only works for mounts performed in kernel space.  It doesn't lend 
> itself to performing mounts in userspace and would force autofs to 
> re-implement mount(1) parsing/struct packing in kernelspace.  Definitely 
> not a good solution.

Or if passed event contains opened mountpoint-to-be.
 
> I'm still partial to the idea that a usenamespace ioctl on 
> /proc/<pid>/mounts is a cleaner solution in the long run, both for 
> automounting as well as for administration tools.

Vetoed.  ioctl() is _not_ an acceptable way to implement any generic
functionality.  It basically says "my interface is a garbage".

And yes, we need to think about a new syscall for mount-related
work.  With sane API - mount(2) one is _not_.  sys_mount() would
still stay, obviously.

  reply	other threads:[~2003-06-19 15:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.nerig52.1j7u3qk@ifi.uio.no>
     [not found] ` <fa.fq0dsjb.1a06mop@ifi.uio.no>
2003-06-19 14:00   ` Mike Waychison
2003-06-19 14:31     ` David Howells
2003-06-19 15:13       ` Mike Waychison
2003-06-19 15:34         ` viro [this message]
2003-06-19 16:53           ` Mike Waychison
2003-06-18 14:20 David Howells
2003-06-18 20:59 ` viro
2003-06-19  9:46   ` David Howells
2003-06-19 14:55     ` viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030619153453.GG6754@parcelfarce.linux.theplanet.co.uk \
    --to=viro@parcelfarce.linux.theplanet.co.uk \
    --cc=dhowells@redhat.com \
    --cc=dhowells@warthog.cambridge.redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.waychison@sun.com \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®