lkml.org 
[lkml]   [2002]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: LSB1.1: /proc/cpuinfo
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:15    [W:0.473 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site