Re: LSB1.1: /proc/cpuinfo

["Eric S. Raymond" <esr@thyrsus.com>]

Erik Andersen <andersen@codepoet.org>:
> I once wrote up /dev/ps and /dev/mounts drivers to eliminate proc
> for embedded systems (pointer available if you care).  It was not
> warmly received, but I did form some opinions in the process.

Sure, I'd like to see this work.
 
> The main things to think about are
>     1) machine readability
> 	Generally speaking the kernel gods have decided that
> 	ASCII is good, binary structures and such are bad (think
> 	endiannes, nfs exports, and similar oddness).

I agree with this decision.  Binary structures would be false economy,
trading away readability and flexibility for a marginal speed gain.

>     2) typing
> 	Right now, if some /proc file prints a number, user space
> 	has to go digging about in the kernel sources to find
> 	what type that thing is -- int, uint, long, long long, etc.
> 	Cant tell without digging in the source.  And what if
> 	someone then changes the type next week -- userspace
> 	then overflows.

I'm not very worried about this.  On modern machines int == long 
and the only case that's a potential headache is long long.  If
longer than int-size data is labeled, we'll be OK.

>     3) field length
> 	When coping a string from /proc (say /proc/mounts),
> 	userspace has to go digging in the kernel source to
> 	find the field length.  So if I copy things into a
> 	static buffer, I may be fine.

I think the right answer to this is usually "don't use a language that
has static buffers". :-)

> So what is needed is a kernelfs virtual filesystem that provides
> kernel info to user space.

I don't care what it's called.  I've seen `sys', 'system', and 'archfs'
thrown around.
 
> It needs a format that provides information as an organized
> directory hierarchy, which each directory and filename
> identifying the nature of the provided information.  Files should
> provide information in ASCII with one value per file (to avoid
> all the tedious parsing), but also provides along with that bit
> of information type and or/length information.  
> 
> In some cases I guess we may also need more complex classes on
> information.  (lists of key-value stuff for example).

One value per *file*?  That seems excessively fine-grained.  Sometimes
you want multiple values per file because the information is a functional
unit for reporting to humans.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Americans have the will to resist because you have weapons. 
If you don't have a gun, freedom of speech has no power.
         -- Yoshimi Ishikawa, Japanese author, in the LA Times 15 Oct 1992