Re: LSB1.1: /proc/cpuinfo
On Thursday 03 January 2002 18:56, Alexander Viro wrote:
> On Thu, 3 Jan 2002, Eric S. Raymond wrote:
> > 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.
> It's more than just a name.
> a) granularity. Current "all or nothing" policy in procfs has
> a lot of obvious problems.
> b) tree layout policy (lack thereof, to be precise).
> c) horribly bad layout of many, many files. Any file exported by
> kernel should be treated as user-visible API. As it is, common mentality
> is "it's a common dump; anything goes here". Inconsistent across
> architectures for no good reason, inconsistent across kernel versions,
> just plain stupid, choke-full of buffer overruns...
> Fixing these problems will _hurt_. Badly. We have to do it, but it
> won't be fast and it certainly won't happen overnight.
Talking from the SysAdmin point of view, procfs is one of the truly
cool things which separates Linux from the others. I'd rather tune
/proc/sys stuff than use sysctl or Solaris' funky /etc/system and
ndd crap. It's the next best thing to "point and click" without going
over to the dark side.
Sure /system is a better name (extra typing becaue we can't have
/sys/sys can we??).
And while you all are at it, why not take a look at some of the naming
conventions that BeOS makes too. I'm _not_ being sarcastic.
Example1: Excellent devfs layout.
Example 2: BeOS root directory is a ramfs off of which the
other drives/filesystems are mounted. (I haven't thought
this one out too much but I could image that it would make
some things easier.)
Example 3: Kernel Modules are in the directory:
Perhaps we could have directories something like:
/dev using devfs !
/system/modules/kernelversion/ (modules in devfs similar tree)
/system/info (for cpuinfo, ioports, meminfo, filesystems, etc.)
/sbin (or even in /system/bin ???)
Example 3: BeOS moves /usr/local stuff to more of a per user
configuration where each user has a $HOME/config directory.
Of course, we would put things like .Xdefaults, kde, gnome, etc.
directories here which vary according to user while still keeping
/usr/local for all users.
My ~/config contains things like "find ~/config -type d | hand edit some"
config/boot (Things my personal boot/login preferences)
Of course, on heavily user subscribed systems, some sort of
NT like COW technique might be nesc. if too many file duplications
occur in the ~/config directories. Having a good /usr/local would
prevent much of this growth, at least in theory. As would strict
Just some thoughts.