Re: Reflection and /proc

[slurn@griffin.engr.sgi.com (Scott Lurndal)]

In article <7bfd4v$a0r7q@fido.engr.sgi.com>, you write:
|> On Mon, Mar 01, 1999 at 04:10:08PM +0100, Davide Bolcioni wrote:
|> > Dominik Kubla wrote:
|> ...
|> > > Right, because the correct answer to your question is getrusage(2).
|> > I beg your pardon ? What field of struct rusage are you referring to ?
|> 

|> Simply calling "(void) getrlimit(RLIMIT_NOFILE,struct_rlimit);"
|> will return in struct_rlimit.rlim_cur the current number of used file
|> descriptors, while struct_rlimit.rlim_max gives you your max limit.

Unless linux has completely redefined the semantics of getrlimit(),
this statement is incorrect.   rlim_cur contains the soft 
limit (i.e. the limit that is currently imposed upon the
process), while rlim_max contains the limit to which the 
rlim_cur value may legally be raised by the process.

There is no defined interface to obtain the current usage
associated with the soft resource limits for a process.

|> 
|> That will work with all resources you can set limits on.
|> 
|> As for the call for "maximum value" of file desctriptors in usage at any
|> time during execution: that is to be done with a syscall-wrapper because
|> you typically only need this information during development/debugging.
|> Most profiling libraries give you this option. No need to bloat the kernel.

Having the maximum file descriptor in use by a process 
(not the number of file descriptors in use), can be useful in situations
where you need to close all open files before performing some task -
if, for example, the file descriptor limit is 2048, then most current
programs such as login which need to close all open files before invoking
the shell, will issue 2048 close system calls - if you know the maximum
you can significantly reduce the number of system calls performed
e.g. at login time.

Better solution would be a 'closeall' system call which starts at 
a given fd and closes all from fd..getdtablesize().

|> 
|> [...]
|> > > > A better example: mounted filesystems. Traditional Unix had /etc/mtab,
|> > > > and the attitude wrt "reflection" (investigation of the state of the
|> > > > system) was that it is more or less unnecessary: the tool performing
|> > > > "set" records the state in ordinary files. Still read() and parse.
|> > > 
|> > > Wrong answer: getmntent(2).
|> > That was in glibc last time I looked; I am not saying parsing /etc/mtab
|> > or its cousin /proc/mounts is a bad idea.
|> 
|> Of course you're right, it should have been getmntent(3).
|> 
|> I would be much happier with a  system call that returned the internal data

Returning internal data structures is generally a bad idea.   It
restricts future changes that can be made  to those
data structures without breaking existing programs.   This is the
big problem that exposing /dev/kmem in unix has caused in the past
(lsof, for example, needs to be frequently rewritten because
operating system internals change from time to time).

|> structures instead of the contents of  a file. Like OSF's getmntinfo(), but
|> if  i am  not wrong  this  is also  a  library call.  Interesting. I  never
|> realized there was  no system call to return you  all mounted file systems.
|> But is that really necessary?  The library does perfectly well what we need.
|> 
|> [...]
|> > The bad solution is nationalized /proc, I gather, so I guess /proc is
|> > intended for scripts and possibly for C programs: /proc/$$/stat is
|> > "right" (scanf one-liner), while /proc/$$/status less so (multi-line
|> > with English). Is this what you mean ?

/proc is an overloaded, overburdened interface in linux.   It was originally
designed as a replacement for ptrace (/proc stands for process), and 
linux has extended it to be more than it was designed for.  The original
/proc implementation in SVR4 provided a binary debugging interface 
and there was no text in the kernel at all, thus no need for nationalization
in the kernel.   Having the ps(1) command format and print the /proc/$$/status
file from its binary contents is much more flexible from a nationalization
standpoint.

|> 
|> Yes. But i guess the whole discussion of NLS in the kernel is moot, because
|> Linus has repeatedly stated that he will never ever accept any such changes.
|> End of topic as far as i am concerned.

Seems like a reasonable statement, to me.

scott
-
Linux-future: thinking about the future of the Linux kernel
Archive:      http://humbolt.nl.linux.org/lists/
Wish list:    http://users.ox.ac.uk/~mert0236/linux-future.html