Re: debugfs in the namespace

From: Greg KH
Date: Thu Dec 16 2004 - 19:23:32 EST

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

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


greg k-h
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at