On Sun, Nov 30, 2008 at 12:42:07AM +0300, Alexey Dobriyan wrote:
On Sat, Nov 29, 2008 at 06:44:49PM +0100, Remi Colinet wrote:
quoted
This patch add a new /proc/mempool file in order to display mempool usage.
The feature can be disabled with CONFIG_PROC_MEMPOOL=N during kernel
configuration.
We're NOT adding config option per proc file.
And can we, please, freeze /proc for not per-process stuff and open debugfs
for random stuff, please?
debugfs has been open for random stuff since the day it was added to the
tree :)
Feel free to put this kind of thing there instead of proc.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Randy Dunlap <hidden> Date: 2008-12-01 18:12:45
On Sat, 29 Nov 2008 15:49:07 -0800 Greg KH wrote:
On Sun, Nov 30, 2008 at 12:42:07AM +0300, Alexey Dobriyan wrote:
quoted
On Sat, Nov 29, 2008 at 06:44:49PM +0100, Remi Colinet wrote:
quoted
This patch add a new /proc/mempool file in order to display mempool usage.
The feature can be disabled with CONFIG_PROC_MEMPOOL=N during kernel
configuration.
We're NOT adding config option per proc file.
And can we, please, freeze /proc for not per-process stuff and open debugfs
for random stuff, please?
debugfs has been open for random stuff since the day it was added to the
tree :)
Feel free to put this kind of thing there instead of proc.
Do distros ship with debugfs enabled?
The problem with using debugfs is that it is very optional IMO.
---
~Randy
From: Matt Mackall <hidden> Date: 2008-12-01 19:21:35
On Mon, 2008-12-01 at 10:12 -0800, Randy Dunlap wrote:
On Sat, 29 Nov 2008 15:49:07 -0800 Greg KH wrote:
quoted
On Sun, Nov 30, 2008 at 12:42:07AM +0300, Alexey Dobriyan wrote:
quoted
On Sat, Nov 29, 2008 at 06:44:49PM +0100, Remi Colinet wrote:
quoted
This patch add a new /proc/mempool file in order to display mempool usage.
The feature can be disabled with CONFIG_PROC_MEMPOOL=N during kernel
configuration.
We're NOT adding config option per proc file.
And can we, please, freeze /proc for not per-process stuff and open debugfs
for random stuff, please?
debugfs has been open for random stuff since the day it was added to the
tree :)
Feel free to put this kind of thing there instead of proc.
Do distros ship with debugfs enabled?
The problem with using debugfs is that it is very optional IMO.
The problem with debugfs is that it claims to not be an ABI but it is
lying. Distributions ship tools that depend on portions of debugfs. And
they also ship debugfs in their kernel. So it is effectively the same
as /proc, except with the 1.0-era everything-goes attitude rather than
the 2.6-era we-should-really-think-about-this one.
Pushing stuff from procfs to debugfs is thus just setting us up for pain
down the road. Don't do it. In five years, we'll discover we can't turn
debugfs off or even clean it up because too much relies on it.
If you think that debugfs is NOT an ABI, then I'm sure you'll be happy
to ack my patch entitled 'gratuitously break usbmon to remind folks that
debugfs is not an ABI'.
--
Mathematics is the supreme nostalgia of our time.
From: Andrew Morton <hidden> Date: 2008-12-01 20:02:10
On Mon, 01 Dec 2008 13:13:31 -0600
Matt Mackall [off-list ref] wrote:
On Mon, 2008-12-01 at 10:12 -0800, Randy Dunlap wrote:
quoted
On Sat, 29 Nov 2008 15:49:07 -0800 Greg KH wrote:
quoted
On Sun, Nov 30, 2008 at 12:42:07AM +0300, Alexey Dobriyan wrote:
quoted
On Sat, Nov 29, 2008 at 06:44:49PM +0100, Remi Colinet wrote:
quoted
This patch add a new /proc/mempool file in order to display mempool usage.
The feature can be disabled with CONFIG_PROC_MEMPOOL=N during kernel
configuration.
We're NOT adding config option per proc file.
And can we, please, freeze /proc for not per-process stuff and open debugfs
for random stuff, please?
debugfs has been open for random stuff since the day it was added to the
tree :)
Feel free to put this kind of thing there instead of proc.
Do distros ship with debugfs enabled?
The problem with using debugfs is that it is very optional IMO.
The problem with debugfs is that it claims to not be an ABI but it is
lying. Distributions ship tools that depend on portions of debugfs. And
they also ship debugfs in their kernel. So it is effectively the same
as /proc, except with the 1.0-era everything-goes attitude rather than
the 2.6-era we-should-really-think-about-this one.
Pushing stuff from procfs to debugfs is thus just setting us up for pain
down the road. Don't do it. In five years, we'll discover we can't turn
debugfs off or even clean it up because too much relies on it.
If you think that debugfs is NOT an ABI, then I'm sure you'll be happy
to ack my patch entitled 'gratuitously break usbmon to remind folks that
debugfs is not an ABI'.
^^ yup.
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Pekka Enberg <hidden> Date: 2008-12-01 20:07:58
On Mon, Dec 1, 2008 at 10:02 PM, Andrew Morton
[off-list ref] wrote:
On Mon, 01 Dec 2008 13:13:31 -0600
Matt Mackall [off-list ref] wrote:
quoted
On Mon, 2008-12-01 at 10:12 -0800, Randy Dunlap wrote:
quoted
On Sat, 29 Nov 2008 15:49:07 -0800 Greg KH wrote:
quoted
On Sun, Nov 30, 2008 at 12:42:07AM +0300, Alexey Dobriyan wrote:
quoted
On Sat, Nov 29, 2008 at 06:44:49PM +0100, Remi Colinet wrote:
quoted
This patch add a new /proc/mempool file in order to display mempool usage.
The feature can be disabled with CONFIG_PROC_MEMPOOL=N during kernel
configuration.
We're NOT adding config option per proc file.
And can we, please, freeze /proc for not per-process stuff and open debugfs
for random stuff, please?
debugfs has been open for random stuff since the day it was added to the
tree :)
Feel free to put this kind of thing there instead of proc.
Do distros ship with debugfs enabled?
The problem with using debugfs is that it is very optional IMO.
The problem with debugfs is that it claims to not be an ABI but it is
lying. Distributions ship tools that depend on portions of debugfs. And
they also ship debugfs in their kernel. So it is effectively the same
as /proc, except with the 1.0-era everything-goes attitude rather than
the 2.6-era we-should-really-think-about-this one.
Pushing stuff from procfs to debugfs is thus just setting us up for pain
down the road. Don't do it. In five years, we'll discover we can't turn
debugfs off or even clean it up because too much relies on it.
If you think that debugfs is NOT an ABI, then I'm sure you'll be happy
to ack my patch entitled 'gratuitously break usbmon to remind folks that
debugfs is not an ABI'.
^^ yup.
Hmm, I thought Documentation/ABI/ was supposed to tell us what's an
ABI you can depend on and what's not. I mean, you shouldn't be
depending on anything but the interfaces documented in
Documentation/ABI/stable/, no?
Hmm, I thought Documentation/ABI/ was supposed to tell us what's an
ABI you can depend on and what's not. I mean, you shouldn't be
depending on anything but the interfaces documented in
Documentation/ABI/stable/, no?
Who is the f*cking MORON that thinks that "documentation" has any meaning
what-so-ever?
The fact that something is documented (whether correctly or not) has
absolutely _zero_ impact on anything at all. What makes something an ABI
is that it's useful and available. The only way something isn't an ABI is
by _explicitly_ making sure that it's not available even by mistake in a
stable form for binary use.
Example: kernel internal data structures and function calls. We make sure
that you simply _cannot_ make a binary that works across kernel versions.
That is the only way for an ABI to not form.
Linus