[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18318.41541.386224.301640@notabene.brown>
Date: Thu, 17 Jan 2008 11:33:09 +1100
From: Neil Brown <neilb@...e.de>
To: Jan Engelhardt <jengelh@...putergmbh.de>
Cc: Karel Zak <kzak@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Miklos Szeredi <miklos@...redi.hu>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
util-linux-ng@...r.kernel.org, linuxram@...ibm.com,
viro@....linux.org.uk, hch@...radead.org, a.p.zijlstra@...llo.nl
Subject: Re: [patch] VFS: extend /proc/mounts
On Thursday January 17, jengelh@...putergmbh.de wrote:
>
> On Jan 17 2008 00:43, Karel Zak wrote:
> >>
> >> Seems like a plain bad idea to me. There will be any number of home-made
> >> /proc/mounts parsers and we don't know what they do.
> >
> > So, let's use /proc/mounts_v2 ;-)
>
> Was not it like "don't use /proc for new things"?
I thought it was "don't use /proc for new things that aren't process
related".
And as the mount table is per process......
A host has a bunch of mounted filesystems (struct super_block), and
each process has some subset of these stitched together into a mount
tree (struct vfsmount / struct namespace).
There needs to be something in /proc that exposes the vfsmount tree.
Arguably there should be something else - maybe in sysfs - that
provides access to the "struct superblock" object.
And there needs to be a clear way to relate information from one with
information from the other.
In the tradition of stat, statm, status, maybe the former should be
/proc/$PID/mountm
:-)
Hey, I just found /proc/X/mountstats. How does this fit in to the big
picture?
NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists