lkml.org 
[lkml]   [1999]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Faster /proc access

Pauline Middelink writes:
> On Mon, May 17, 1999 at 03:22:01PM +0200, Jos Hulzink wrote:

>> In a kernel-wishlist for 2.1 / 2.2 there was a wish about faster /proc
>> access (i.e. binary /proc). I thought this was a nice project for me to
>> start real kernel development (in the past, I've only hacked a bit and
>> worked on the GGI project) For I'm new to this list, I want to ask if any
>> important messages on this topic have been on this list in the past.
>> (maybe this project is cancelled / already done ?)
>
> Have a look at sysctl. It delivers much of the /proc data and
> we (i?) am looking in accessing more of the /proc data from the
> sysctl interface. this way /proc will become a simple human
> readable mirror of the sysctl data, and programs should be
> able to access the data in a native binary format...

For serious use, that call is junk. It is bad to need to make one system
call per data item. It also doesn't offer the right information.

Think of a call that would be used this way:

__u64 results[3];
const int request[] = {FOO_SESS, FOO_PPID, FOO_CMD};
err = foo(pid,request,results);
if(err) exit(1);
printf("SESS %Ld\n", results[0]);
printf("PPID %Ld\n", results[1]);
printf("CMD %8.8s\n", &(results[2]));

It is also OK to fill in a union of structs, with each possible struct
containing a set of information that goes well together with the same
sort of locking and security issues.

It is OK to read this information from a /proc/12345/.bindata file,
though that isn't quite as fast.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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