[RFC] Don't replace /proc (Re: Digest message 23, PROPOSAL: /proc standards)

[Brad Chapman]

Everyone,

--- [e-mail] 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" <[e-mail]>
>To: [e-mail]
>Cc: [e-mail]
>Subject: Re: PROPOSAL: /proc standards (was dot-proc interface [was: /proc
>
>
>>On 20011106 Erik Hensema wrote:
>>Stephen Satchell ([e-mail]) 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 0.0.0.0.0.0.0.0.1 of the
>>>Rules of /Proc:
>>
>>Agreed.
>>
>>>
>>>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
>(write("/proc/the/fd",&myValue)).
>
>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

=====
Brad Chapman

Permanent e-mails: [e-mail]
		   [e-mail]
Alternate e-mails: [e-mail]
		   [e-mail]

__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com