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.
I don't think there's all that much wrong with the current layout,
except the two dummy zeroes at the end. Or, something else
On Thu, Jan 17, 2008 at 09:36:11AM +0100, Miklos Szeredi wrote:
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?
I think the scheme devised by Ram is
On Jan 17, 2008, at 3:55 AM, Miklos Szeredi wrote:
Hey, I just found /proc/X/mountstats. How does this fit in to the
big
picture?
It seems to show some counters for NFS mounts, no other filesystem
uses it. Format looks rather less nice, than /proc/X/mounts (why do
we need long english
The reason, why this patch was dug up, is that if the bdi-sysfs patch
is going to use device numbers to identify BDIs, then there should be
a way for the user to map the device number into mount(s).
But it's useful regardless of the bdi-sysfs patch.
Can this be added to -mm?
In theory it could
On Wed, 16 Jan 2008 23:12:31 +0100
Miklos Szeredi [EMAIL PROTECTED] wrote:
The reason, why this patch was dug up, is that if the bdi-sysfs patch
is going to use device numbers to identify BDIs, then there should be
a way for the user to map the device number into mount(s).
But it's useful
The reason, why this patch was dug up, is that if the bdi-sysfs patch
is going to use device numbers to identify BDIs, then there should be
a way for the user to map the device number into mount(s).
But it's useful regardless of the bdi-sysfs patch.
Don't know what that is.
On Wed, Jan 16, 2008 at 02:30:51PM -0800, Andrew Morton wrote:
On Wed, 16 Jan 2008 23:12:31 +0100
Miklos Szeredi [EMAIL PROTECTED] wrote:
In theory it could break userspace, but I think it's very unlikely to
do so, because stuff is added only at the end of the lines, and
because most
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?
-
To unsubscribe from this list: send the
On Thu, 17 Jan 2008 00:58:06 +0100 (CET) Jan Engelhardt [EMAIL PROTECTED]
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 ;-)
On Thursday January 17, [EMAIL PROTECTED] 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
On Jan 17 2008 11:33, Neil Brown wrote:
On Thursday January 17, [EMAIL PROTECTED] 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
Andrew Morton 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.
There is a lot of precedent for adding fields at the end. Since the
last fields in current /proc/*/mounts are dummy fields anyway, it
doesn't
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
On Wed, Jan 16, 2008 at 04:09:30PM -0800, Andrew Morton wrote:
On Thu, 17 Jan 2008 00:58:06 +0100 (CET) Jan Engelhardt [EMAIL PROTECTED]
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
14 matches
Mail list logo
