>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?
In any event, is the format of process info (actually should be in /proc) or
the-other-stuff the issue? If it is the latter, the compatibility issue has
a fairly easy solution...
>But I agree: /proc is populated with files that don't really belong >there.
>Maybe everything should be moved to /kernel? (except for the
>process info, offcourse).
I like this idea a lot, and so far I haven't heard any objections, save
compatability...
>It will be very, very hard for distributors to create a distribution >which
>runs one the native 2.6 /proc interface as soon as 2.6 comes >out. I think
>we must assume rewriting things like procps, init >scripts, etc. will only
>start as soon as 2.6 comes out. We should >provide some transitional period
>for userspace to adapt, but make >clear to everybody that compatibility
>isn't going to last forever.
Simple solution is to move /kernel stuff of /proc to /kernel (new format,
bin, ascii, whatever) and put transition code (old code still serving the
old format /kernel stuff) serving in /proc. Make the backwards compatibility
/proc a compile option. That way, userland developers will have time to
migrate to /kernel (or whatever it should be called). Not too much effort,
makes userland developers not sweat to death...
Will Knop
[email protected]
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
In article <[email protected]>,
William Knop <[email protected]> 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.