lkml.org 
[lkml]   [2001]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: PROPOSAL: /proc standards (was dot-proc interface [was: /proc
Date
In article <F57jukJ1zkc6g9wHRQa0000b09f@hotmail.com>,
William Knop <w_knop@hotmail.com> wrote:
>
>>Yes, but I meant a program which reads a single binary value and >outputs
>>it as ascii, as a generic layer between the binary /proc and >the ascii
>>world of shell scripts.
>>
>>I don't like a binary /proc.
>
>The binary issue could very easily be solved, as you said, by a small
>generic program to do the conversion. Upside it only shell scripts need
>this, while more advanced (lower level) programs will get better preformance
>out of binary format. Downside? I am not sure I see the problem. If a
>program needs to get a lot of /proc info frequently, a binary interface will
>be faster. Idealistically, do we want the kernel interfaces binary or ascii?
>Do we want them to preform best with (be native to) shell scripts or
>programs?

Both. /proc in ascii for shell scripts etc, and sysctl() in binary
for C programs and the like.

Something like

sysctl(SYSCTL_GET, "fs.file-max", SYSCTL_TYPE_INT, &val, sizeof(val))

It gets you free type checking as well.

Perhaps you even want a opendir()/getdents() type sysctl function
so you can walk the tree without /proc being mounted at all.

Mike.
--
"Only two things are infinite, the universe and human stupidity,
and I'm not sure about the former" -- Albert Einstein.

-
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/

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