lkml.org 
[lkml]   [2001]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: system call for process information?
Date
Nathan Paul Simons writes:
> On Mon, Mar 12, 2001 at 09:21:37PM +0000, Guennadi Liakhovetski wrote:

>> CPU utilisation. Each new application has to calculate it (ps, top, qps,
>> kps, various sysmons, procmons, etc.). Wouldn't it be worth it having a
>> syscall for that? Wouldn't it be more optimal?
>
> No, it wouldn't be worth it because you're talking about
> sacrificing simplicity and kernel speed in favor of functionality.
> This has been know to lead to "bloat-ware". Every new syscall you

Bloat removal: being able to run without /proc mounted.

We don't have "kernel speed". We have kernel-mode screwing around
with text formatting.

> add takes just a little bit more time and space in the kernel, and
> when only a small number of programs will be using it, it's really
> not worth it. This time and space may not be large, but once you
> get _your_ syscall added, why can't everyone else get theirs added
> as well? And so, after making about a thousand specialized syscalls
> standard in the kernel, you end up with IRIX (from what I've heard).

This isn't just for him. Many people have wanted it.

> Don't even get me started about opening security holes, and
> increasing code complexity. Please do a search for every other

I'll get you started. Compare:

1. variable-length ASCII strings with undefined ad-hoc syntax
2. array of fixed-size (64-bit) values

> ps - CPU time is cheap, that's why they don't charge for it anymore.
> Programmer time is _not_.

Parsing costs programmer time.
-
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:29    [W:0.086 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site