Re: LSB1.1: /proc/cpuinfo
- To: Alexander Viro <firstname.lastname@example.org>
- Cc: Joerg Schilling <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
- Subject: Re: LSB1.1: /proc/cpuinfo
- From: "Eric S. Raymond" <email@example.com>
- Date: Thu, 3 Jan 2002 19:52:07 -0500
- Message-id: <20020103195207.A31252@thyrsus.com>
- Mail-followup-to: "Eric S. Raymond" <firstname.lastname@example.org>, Alexander Viro <email@example.com>, Joerg Schilling <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com
- Reply-to: firstname.lastname@example.org
- In-reply-to: <Pine.GSO.email@example.com>
- References: <20020103190219.B27938@thyrsus.com> <Pine.GSO.firstname.lastname@example.org>
Alexander Viro <email@example.com>:
> 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.
I'm willing to work on this. Is there anywhere I can go to read up on
current proposals before I start coding?
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
When all government ...in little as in great things... shall be drawn to
Washington as the center of all power; it will render powerless the checks
provided of one government on another, and will become as venal and oppressive
as the government from which we separated." -- Thomas Jefferson, 1821