[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: LSB1.1: /proc/cpuinfo

Joerg Schilling <schilling@fokus.gmd.de>:
> The way /proc works has been introduced by Plan 9 in the first half
> of the 80s.  What Linux added as an abuse of the /proc filesytem in
> principle is a Plan 9 idea too. It makes sense to have something
> similar, but please please _not_ inside the /proc tree.
> Sun is planning to have /sys with similar backgound in a future
> version of Solaris so it wouls make sense to talk to the Solaris
> kernel kackers to have a common way to go for the new /sys tree.

Well, hell.  If the "/proc is a blight on the face of the planet" ranting that
I've been hearing is just about the *name* /proc, then let's separate the
name issue from the content issue.

The kind of non-per-process information that is now in /proc needs to still
be there for many purposes; autoconfiguration is the one that is bugging 
me right now, but cluster management is just as important.

If moving /proc/cpuinfo to /sys/cpuinfo means people will stop trying to make
the cpuinfo information go away, then By all means let's move it.

I want /sys/dmi, too.

I'm willing to write up a proposal for /sys that would migrate the `unclean'
/proc stuff over to ./sys, and I'm willing to write the kernel patches to
implement the renaming.

I'm motivated to attack this right now because it touches the work I'm
doing on kernel autoconfiguration.

(Copied to the linux-kernel mailing list because of a parallel argument
happening there...)
		<a href="http://www.tuxedo.org/~esr/";>Eric S. Raymond</a>

The common argument that crime is caused by poverty is a kind of
slander on the poor.
	-- H. L. Mencken

Reply to: