* [RFC] Don't replace /proc (Re: Digest message 23, PROPOSAL: /proc standards)
[not found] <200111062247.fA6Ml2E11597@lists.us.dell.com>
@ 2001-11-07 0:32 ` Brad Chapman
0 siblings, 0 replies; only message in thread
From: Brad Chapman @ 2001-11-07 0:32 UTC (permalink / raw
To: linux-kernel
Everyone,
--- linux-kernel-digest-request@lists.us.dell.com 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" <jamagallon@able.es>
>To: erik@hensema.net
>Cc: linux-kernel@vger.kernel.org
>Subject: Re: PROPOSAL: /proc standards (was dot-proc interface [was: /proc
>
>
>>On 20011106 Erik Hensema wrote:
>>Stephen Satchell (satch@concentric.net) 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: kakadu_croc@yahoo.com
jabiru_croc@yahoo.com
Alternate e-mails: kakadu@adelphia.net
kakadu@netscape.net
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2001-11-07 0:33 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <200111062247.fA6Ml2E11597@lists.us.dell.com>
2001-11-07 0:32 ` [RFC] Don't replace /proc (Re: Digest message 23, PROPOSAL: /proc standards) Brad Chapman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.