Here's my go at a new design for /proc. I designed it from a userland
point of view and tried not to drown myself into details.
Design goals
============
- Backward compatibility
The current /proc interface is coded into many applications.
A new design must leave room for backward compatibility.
- Forward compatibility
The new interface must be clearly defined and must not change
in the future, unless that change is clearly indicated and it
would cause horrible pain maintaining the current interface.
(Note: I mean the interface to userland, kernel interfaces may
change as much as they like)
- Parsable by applications
Information in /proc isn't really meant for humans to read.
Maybe programmers, but they aren't human anyway. The new /proc
interface must be parsable by applications as easily as
possible.
- Readable by humans
When there's no compelling need to obscure information, don't.
- As simple as possible
Don't bloat the interface with all kinds of fancy decorations.
Let's leave that to userspace.
>From these goals I come to the following design:
Design
======
- Multiple values per file when needed
A file is a two dimensional array: it has lines and every line
can consist of multiple fields.
A good example of this is the current /proc/mounts.
This can be parsed very easily in all languages.
No need for single-value files, that's oversimplification.
- No headers, no pretty formatting
Headers are nice to humans, but applications tend to dislike
them. Same goes for formatting.
An example of this is in /proc/partitions or -- horrors --
/proc/meminfo.
- ASCII values
ASCII is the only format which can be read by humans, shell
scripts, perl, C and the rest of the world.
- Maybe we should move out of /proc
Since this design must leave room for backwards compatibility
we must assume the current /proc stays around for a while. I
propose we create a new kernelfs which is to be mounted at
/kernel.
- Mandatory documentation
Each and every value must be documented. This documentation
may be very, very basic, but it must clearly define the entry
and its intention. This is forward compatibility.
As an example, this is how I would organize the info currently in
/proc/meminfo (any boy, that file is UGLY!):
Every value is in bytes. Rounding to kbytes or mbytes should be done
in userspace.
New Current entry in /proc/meminfo
--------------- -----------------------------------
mem/total MemTotal
mem/free MemFree
mem/shared MemShared
mem/buffers Buffers
mem/cached Cached
mem/active Active
mem/inactive Inactive
mem/high/total HighTotal
mem/high/free HighFree
mem/low/total LowTotal
mem/low/free LowFree
mem/swap/total SwapTotal
mem/swap/free SwapFree
mem/swap/cached SwapCached
mem/swap/files (current /proc/swaps)
-- Erik Hensema (erik@hensema.net) I'm on the list, no need to Cc: me, though I appreciate one if your mailer doesn't support the References header. - 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/
This archive was generated by hypermail 2b29 : Wed Nov 07 2001 - 21:00:35 EST