public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, util-linux-ng@vger.kernel.org,
	linuxram@us.ibm.com, viro@ftp.linux.org.uk, hch@infradead.org,
	a.p.zijlstra@chello.nl
Subject: Re: [patch] VFS: extend /proc/mounts
Date: Thu, 17 Jan 2008 03:33:09 +0000	[thread overview]
Message-ID: <20080117033309.GX27894@ZenIV.linux.org.uk> (raw)
In-Reply-To: <E1JFGUp-00054z-KQ@pomaz-ex.szeredi.hu>

On Wed, Jan 16, 2008 at 11:12:31PM +0100, Miklos Szeredi wrote:
> The alternative (and completely safe) solution is to add another file
> to proc.  Me no likey.

Since we need saner layout, I would strongly suggest exactly that.

> major:minor -- is the major minor number of the device hosting the filesystem

Bad description.  "Value of st_dev for files on that filesystem", please -
there might be no such thing as "the device hosting the filesystem" _and_
the value here may bloody well be unrelated to device actually holding
all data (for things like ext2meta, etc.).

> 1) The mount is a shared mount.
> 2) Its peer mount of mount with id 20
> 3) It is also a slave mount of the master-mount with the id  19
> 4) The filesystem on device with major/minor number 98:0 and subdirectory
> 	mnt/1/abc makes the root directory of this mount.
> 5) And finally the mount with id 16 is its parent.

I'd suggest doing a new file that would *not* try to imitate /etc/mtab.
Another thing is, how much of propagation information do we want to
be exposed and what do we intend to do with it?  Note that "entire
propagation tree" is out of question - it spans many namespaces and
contains potentially sensitive information.  So we won't see all nodes.

What do we want to *do* with the information about propagation?

  parent reply	other threads:[~2008-01-17  3:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-16 22:12 [patch] VFS: extend /proc/mounts Miklos Szeredi
2008-01-16 22:30 ` Andrew Morton
2008-01-16 23:15   ` Miklos Szeredi
2008-01-16 23:43   ` Karel Zak
2008-01-16 23:58     ` Jan Engelhardt
2008-01-17  0:09       ` Andrew Morton
2008-01-17  3:35         ` Al Viro
2008-01-17  0:33       ` Neil Brown
2008-01-17  1:17         ` Jan Engelhardt
2008-01-17  8:55         ` Miklos Szeredi
2008-01-17 15:36           ` Chuck Lever
2008-01-17  2:45   ` H. Peter Anvin
2008-01-17  3:33 ` Al Viro [this message]
2008-01-17  8:36   ` Miklos Szeredi
2008-01-17 10:34     ` Karel Zak

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=20080117033309.GX27894@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxram@us.ibm.com \
    --cc=miklos@szeredi.hu \
    --cc=util-linux-ng@vger.kernel.org \
    --cc=viro@ftp.linux.org.uk \
    /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