Re: [RESEND][PATCH] Add /proc/mempool to display mempool usage

Re: [RESEND][PATCH] Add /proc/mempool to display mempool usage

[Alexey Dobriyan]

On Sat, Nov 29, 2008 at 06:44:49PM +0100, Remi Colinet wrote:
> 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?
--
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

Re: [RESEND][PATCH] Add /proc/mempool to display mempool usage

[Greg KH]

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:
> > 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

Re: [RESEND][PATCH] Add /proc/mempool to display mempool usage

[Randy Dunlap]

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:
> > On Sat, Nov 29, 2008 at 06:44:49PM +0100, Remi Colinet wrote:
> > > 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

Re: [RESEND][PATCH] Add /proc/mempool to display mempool usage

[Matt Mackall]

On Mon, 2008-12-01 at 10:12 -0800, Randy Dunlap wrote:
> 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:
> > > On Sat, Nov 29, 2008 at 06:44:49PM +0100, Remi Colinet wrote:
> > > > 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.

Re: [RESEND][PATCH] Add /proc/mempool to display mempool usage

[Andrew Morton]

On Mon, 01 Dec 2008 13:13:31 -0600
Matt Mackall <mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ@public.gmane.org> wrote:

> On Mon, 2008-12-01 at 10:12 -0800, Randy Dunlap wrote:
> > 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:
> > > > On Sat, Nov 29, 2008 at 06:44:49PM +0100, Remi Colinet wrote:
> > > > > 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

Re: [RESEND][PATCH] Add /proc/mempool to display mempool usage

[Pekka Enberg]

On Mon, Dec 1, 2008 at 10:02 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Mon, 01 Dec 2008 13:13:31 -0600
> Matt Mackall <mpm@selenic.com> wrote:
>
>> On Mon, 2008-12-01 at 10:12 -0800, Randy Dunlap wrote:
>> > 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:
>> > > > On Sat, Nov 29, 2008 at 06:44:49PM +0100, Remi Colinet wrote:
>> > > > > 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?

Re: [RESEND][PATCH] Add /proc/mempool to display mempool usage

[Linus Torvalds]

On Mon, 1 Dec 2008, Pekka Enberg wrote:
> 
> 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

Re: [RESEND][PATCH] Add /proc/mempool to display mempool usage

[Linus Torvalds]

On Mon, 1 Dec 2008, Linus Torvalds wrote:
> 
> 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.

Of course, the alternate form is to make it so _useless_ that people won't 
use it even if it's available, and I guess we do have those kinds of 
interfaces too. But we generally don't need to worry about unused and 
useless interfaces very much, so it doesn't tend to matter much.

			Linus
--
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

Re: [RESEND][PATCH] Add /proc/mempool to display mempool usage

[Pekka Enberg]

Hi Linus,

On Mon, 1 Dec 2008, Pekka Enberg wrote:
>> 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?

On Mon, Dec 1, 2008 at 10:12 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> Who is the f*cking MORON that thinks that "documentation" has any meaning
> what-so-ever?

Me, I suppose. At least that's the impression I got when being asked
to document any new kmemtrace debugfs files, for example.

On Mon, Dec 1, 2008 at 10:12 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> 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.

OK, but why do we have those different ABI "stages" in
Documentation/ABI then? The README file there seems to contradict what
you say. Or maybe I'm reading it wrong...

                         Pekka
--
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

Re: [RESEND][PATCH] Add /proc/mempool to display mempool usage

[Matt Mackall]

On Tue, 2008-12-02 at 00:02 +0200, Pekka Enberg wrote:
> Hi Linus,
> 
> On Mon, 1 Dec 2008, Pekka Enberg wrote:
> >> 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?
> 
> On Mon, Dec 1, 2008 at 10:12 PM, Linus Torvalds
> <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> > Who is the f*cking MORON that thinks that "documentation" has any meaning
> > what-so-ever?
> 
> Me, I suppose. At least that's the impression I got when being asked
> to document any new kmemtrace debugfs files, for example.
> 
> On Mon, Dec 1, 2008 at 10:12 PM, Linus Torvalds
> <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> > 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.
> 
> OK, but why do we have those different ABI "stages" in
> Documentation/ABI then? The README file there seems to contradict what
> you say. Or maybe I'm reading it wrong...

If the terrain and the map do not agree, follow the terrain. – Swedish
army manual.

If code uses a public interface and we break that interface, we will get
unhappy users. Putting stuff in debugfs/ in a released kernel makes it
public. That's the terrain.

-- 
Mathematics is the supreme nostalgia of our time.

--
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

Re: [RESEND][PATCH] Add /proc/mempool to display mempool usage

[Linus Torvalds]

On Tue, 2 Dec 2008, Pekka Enberg wrote:
> 
> OK, but why do we have those different ABI "stages" in
> Documentation/ABI then? The README file there seems to contradict what
> you say. Or maybe I'm reading it wrong...

I think that whole Documentation/ABI stuff is utter tosh, and should just 
be thrown out, whenever it talks about interfaces that are _not_ ABI's.

IOW, it's fine to document things that are actually supposed to be stable, 
but:

 - assuming that non-documentation means that it's not an ABI is bogus
   and wrong.

 - explicitly documenting something as "not an ABI" is wrongheaded and 
   stupid, because it's meaningless and only sets people up for being 
   disappointed later.

So yeah, I think we might as well remove the "testing" one. Right now it 
can act in two ways:

 - as documentation on how to use it (ie as "stable").

   This is fine, but then it shouldn't be called "testing", should it?

 - as an excuse for whining later when it _did_ get used, and people break 
   exported ABI's, and we need to revert the breakage.

   And this is the one that I don't think is valid. No amount of 
   documentation will ever make something less stable.

So as far as I'm concerned, "testing" should either go away (as a way to 
discourage people from even _knowing_ about the things, and hoping that 
they never get used), or it should be moved to "stable".

And in the end, nothing is ever totally black-and-white or quite that 
simple, but that's the mindset you should have.

Finally, when it comes to documentation as a bigger issue:

 - wrong documentation is irrelevant. It doesn't matter if the 
   documentation says "X", when the code does "Y".

   If people rely on "Y", then pointing at the docs and saying "but you 
   should never have relied on it, because teh docs say X" is totally and 
   utterly bogus. The _documentation_ was wrong. Don't ever use incorrect 
   documentation as an excuse. 

Too many people seem to think that documentation is the "final" argument. 
It's not. Not even close. It's a hint and a help, but it's _secondary_ to 
code. Anybody who doesn't understand that should never be allowed to write 
code (or documentation, for that matte).

[ The same is true of assert()'s in code too - I've seen too many damn 
  asserts that were simply _wrong_, and then when they triggered, people 
  would always blindly assume that the assert() was right, and try to 
  change the code to suit. For some reason people have a hard time asking 
  themselves whether perhaps the bug was in the assertion itself. ]

			Linus
--
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

Re: [RESEND][PATCH] Add /proc/mempool to display mempool usage

[Michael Kerrisk]

On Mon, Dec 1, 2008 at 9:54 PM, Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
>
>
> On Tue, 2 Dec 2008, Pekka Enberg wrote:
>>
>> OK, but why do we have those different ABI "stages" in
>> Documentation/ABI then? The README file there seems to contradict what
>> you say. Or maybe I'm reading it wrong...
>
> I think that whole Documentation/ABI stuff is utter tosh, and should just
> be thrown out, whenever it talks about interfaces that are _not_ ABI's.
>
> IOW, it's fine to document things that are actually supposed to be stable,
> but:
>
>  - assuming that non-documentation means that it's not an ABI is bogus
>   and wrong.

Agreed.  (When so much is much is undocumented anyway, there is no way
that lack of documentation can be used to signal "this is not an ABI.)

>  - explicitly documenting something as "not an ABI" is wrongheaded and
>   stupid, because it's meaningless and only sets people up for being
>   disappointed later.

Agreed.

[...]

> Finally, when it comes to documentation as a bigger issue:
>
>  - wrong documentation is irrelevant. It doesn't matter if the
>   documentation says "X", when the code does "Y".
>
>   If people rely on "Y", then pointing at the docs and saying "but you
>   should never have relied on it, because teh docs say X" is totally and
>   utterly bogus. The _documentation_ was wrong. Don't ever use incorrect
>   documentation as an excuse.

Agreed.

> Too many people seem to think that documentation is the "final" argument.
> It's not. Not even close. It's a hint and a help, but it's _secondary_ to
> code. Anybody who doesn't understand that should never be allowed to write
> code (or documentation, for that matte).

While clearly documentation is not the final answer, I think you
undervalue it somewhat, and I think it's worth mentioning two specific
points.  Documentation may be secondary to code, but it can help a
lot, especially if:

* The documentation is done at the same time as the code (by the
developer, or by someone working with the developer).  This typically
makes the developer think more about the code they are writing.  It
also gives others to more quickly understand the code with the aim of
reviewing the code and/or API design, and perhaps testing it.  There
simply isn't enough review and testing going on, and documentation can
make a real difference there, IMO.

*  While the "but you should never have relied on it, because the docs
say X" argument may not hold, there is one important way that I think
documentation can still help: explicitly saying that "the behavior is
unspecified around point X, and other code should not rely on a
specific behavior".  This legitimately allows developers to change the
behavior around point X in the future.  (I made the point at LPC, if
you force users to read the code behind an API, then you end up
creating a "tight spec", since they will do exactly what the code
permits.  In this sense, documentation can be used to "loosen" the
spec.)

Cheers,

Michael




-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
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