[lkml]   [2001]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[RFC] Don't replace /proc (Re: Digest message 23, PROPOSAL: /proc standards)

--- wrote:
> 23. Re: PROPOSAL: /proc standards (was dot-proc interface [was: /proc (J .
> A . Magallon)
>Message: 23
>Date: Tue, 6 Nov 2001 23:53:03 +0100
>From: "J . A . Magallon" <>
>Subject: Re: PROPOSAL: /proc standards (was dot-proc interface [was: /proc
>>On 20011106 Erik Hensema wrote:
>>Stephen Satchell ( wrote:
>>>The RIGHT tool to fix the problem is the pen, not the coding pad. I
>>>hereby pick up that pen and put forth version of the
>>>Rules of /Proc:
>>>7) The /proc data may include comments. Comments start when an unescaped
>>>hash character "#" is seen, and end at the next newline \n. Comments may
>>>appear on a line of data, and the unescaped # shall be treated as end of
>>>data for that line.
>Well, perhaps this is a stupid idea. But I throw it.
>ASCII is good for humans, bin is good to read all info easily in a program.
>Lets have both.
>Once I thought the solution could be to make /proc entries behave
>differently in two scenarios. Lets suppose you could open files in ASCII
>or binary mode. An entry opened in ASCII returns printable info and opened
>in binary does the binay output. As there is no concept of ASCII or binary
>files in low-level file management, the O_DIRECT flag (or any new flag) could
>be used.
>And (supposing all fies in /proc are 0-sized) perhaps a seek position could be
>defined for reading a format string or a set of field names, ie:
>lseek(SEEK_FORMAT); read(...);
>Same for writing, opening in "wa" allows to write a formatted number (ie,
>echo 0xFF42 > /proc/the/fd) and "wb" allows to write binary data
>Just an idea...

I have a better idea. IMO, DON'T CHANGE /proc. Period.

The reason is that it would take a horribly long time to actually
migrate all the broken userspace programs over to the new, changed, updated
/proc. Therefore, I have a proposal: create TWO new filesystems:

procfs2 - PROCess FileSystem version 2
A listing of all system processes in whatever format wins

kernelfs - KERNEL FileSystem
A configuration/feedback kernel interface in whatever
format wins

Put ALL process-related stuff in procfs2, and all kernel-related
stuff (/proc/bus, /proc/pci, /proc/sys, /proc/net, etc.......) in kernelfs.
Then choose how many kernel blocks procfs1 will remain available (i.e.
the Great Overlord Linus decrees, "Thou shalt not remove procfs1 until 2.7")

This way, people who hate /proc get their new format, every single
person who wrote a program based on /proc can take their time migrating to the
new formats, and you get more granular control over kernel-related stuff
(i.e. if you don't need to mess with kernel settings, don't mount kernelfs).

Comments, anyone? From the e-mails I've been reading, it seems
that this way, everybody wins....... unless you consider code duplication.....

>J.A. Magallon


Brad Chapman

Permanent e-mails:
Alternate e-mails:

Do You Yahoo!?
Find a job, post your resume.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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