public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Grzegorz Kulewski <kangur@polcom.net>
Cc: Pete Zaitcev <zaitcev@redhat.com>,
	Mike Waychison <Michael.Waychison@Sun.COM>,
	linux-kernel@vger.kernel.org
Subject: Re: debugfs in the namespace
Date: Thu, 16 Dec 2004 16:21:24 -0800	[thread overview]
Message-ID: <20041217002124.GA11898@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.60.0412170101530.25628@alpha.polcom.net>

On Fri, Dec 17, 2004 at 01:08:05AM +0100, Grzegorz Kulewski wrote:
> On Thu, 16 Dec 2004, Greg KH wrote:
> >Disadvantage:
> >- it puts a non-process type thing into /proc which is what I am
> >  specifically trying to get away from doing.
> >
> >Only process related things _should_ be in /proc.  Now if I can ever
> >fully achieve that goal in my lifetime is something that is left to be
> >seen...
> 
> Ok, probably - but who said this?

Well, if you can't find it written down anymore, here, I'll give you a
quote:
	"/proc should only be for process related things."
			- Greg Kroah-Hartman, December 16, 2004

> IIRC there is no standard describing what should be in proc and what
> should not.

We have one now, see above :)

> I do not think that after so many years of storing everyting in /proc
> there is any chance that you will remove all not [0-9]* dirs and files
> from /proc before the sun will stop lighting... :-)

Hey, everyone needs a windmill to chase after to define their life's
purpose...

> Many, really _many_, binary only apps are using proc for 999999
> different (often stupid) things

Yes, I'm well aware of the /proc/cpu abusing that is done by many binary
programs (oracle, jvm, etc.)  But it's the other things that definitely
don't belong in there (like the /proc/drivers/ tree stuff) that should
get moved out over time.  What do you think I've been doing over the
past 3 years with sysfs...

> - how you will change that? There is way too late for such change, in
> my opinion.

Slowly, over time, with creating good, standardised things like sysfs
(which has order to it), and fun, anarchistic things like debugfs.
Between the combination of the two, we'll get closer to an ideal, which
is better than what we have today.

> And polluting / with proc, sys, dev, selinux, debug and who knows what 
> else is at least equally bad.

Why?  Each location is defined to have one, specific, well defined thing
there that people can count on (or not count on in the case of /debug.)

thanks,

greg k-h

  reply	other threads:[~2004-12-17  0:22 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-16 19:00 debugfs in the namespace Pete Zaitcev
2004-12-16 19:08 ` Greg KH
2004-12-16 19:33   ` Pete Zaitcev
2004-12-16 19:42     ` Greg KH
2004-12-17 19:08       ` Pavel Machek
2004-12-18 17:49         ` Jörn Engel
2004-12-16 20:00     ` Jan Engelhardt
2004-12-16 21:51   ` Mike Waychison
2004-12-16 22:18     ` Greg KH
2004-12-16 22:45       ` Pete Zaitcev
2004-12-16 22:53         ` Greg KH
2004-12-16 23:39           ` Grzegorz Kulewski
2004-12-16 23:51             ` Greg KH
2004-12-17  0:08               ` Grzegorz Kulewski
2004-12-17  0:21                 ` Greg KH [this message]
2004-12-17  1:15                   ` Grzegorz Kulewski
2004-12-17  1:23                     ` Greg KH
2004-12-17  7:48             ` Jan Engelhardt
2004-12-16 23:21         ` Bernd Eckenfels
2004-12-17  2:27           ` Phil Lougher
2004-12-17  7:23       ` Jan Engelhardt
2004-12-17 17:22       ` debugfs in the namespace [u] Martin Schlemmer [c]
2004-12-16 23:29   ` debugfs in the namespace Pedro Venda (SYSADM)
2004-12-18 22:24   ` Matt Mackall
2004-12-17  4:06 ` H. Peter Anvin
2004-12-17 18:39   ` John Levon
     [not found] <fa.al1ango.pl0rak@ifi.uio.no>
     [not found] ` <fa.ddml8me.1k46obg@ifi.uio.no>
2004-12-17  5:51   ` Bodo Eggert

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=20041217002124.GA11898@kroah.com \
    --to=greg@kroah.com \
    --cc=Michael.Waychison@Sun.COM \
    --cc=kangur@polcom.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zaitcev@redhat.com \
    /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