[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reflection and /proc
On Mon, Mar 01, 1999 at 06:51:58PM -0800, Scott Lurndal wrote:
> 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.
Oops. Looks like i screwed that one up. After rereading the man page it is
obvious that my earlier statements about this are completely bogus. Hmm,
hmm! Where are the brown paper bags?
> There is no defined interface to obtain the current usage associated with
> the soft resource limits for a process.
I stand corrected. But do we really need a system call for this. I think
this is something that should be solved at lib level...
> 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.
I see where you're aiming, but IMHO this is not necessary at all. The
application should do it's own bookkeeping and know what file descriptors
are open. As for your example: i very much prefer the penalty for an
unecessary system call to added complexity and possible incompatibility:
Did you ever try to port from/to HP-UX? Their pty handling will drive you
crazy...
> Better solution would be a 'closeall' system call which starts at a given
> fd and closes all from fd..getdtablesize().
But that can be done in user-space as well. Why insist on a system call? I
guess i know your answer: speed. But then look at NT, they sacrificed a
reasonably good architecture (WRT device drivers and user-interface) when
moving from 3.5 to 4.0. Result: a buggy video driver can crash the system
which was very hard in 3.5.
So my argument is: sometimes you need to know where to draw the line. I am
not (yet) convinced we need to cross it here.
> 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).
Of course i misphrased that: I don't want to return the internal data
structure but the data that is kept therein, not the data from a file which
might be out of date. (Happend to me: mount was refusing to mount a file
system which was not mounted, just because there was a bogus entry in
/etc/mtab. After cat-ing /proc/mounts to /etc/mtab every thing worked as
intened.) So essentially it looks as if i an calling for a system call i
guess, but i would settle for a "better" libc function any time of day.
From looking at the getmntinfo() man page of DEC-Unix, this is exactely how
they do it. Does that sound too confusing? Is this making any sense at all?
> /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.
I stand corrected. But that perfectly well demonstrates why i am against
proprietary linux extensions. A split into a SVR4-compliant procfs and
a kernfs a la BSD would have made more sense, but...
> |> 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.
Am i detecting sarcasm here? ;-)
Yours,
Dominik Kubla
-
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