>
> > GLibC does not have setproctitle(3) so they used some
> > hackish implementation bundled with that programs. Unfortunatelly this
> > implementation depended on subtle bug in Linux procfs that was there for ages:
> > cmdline will always return FULL first argument of program even if program
> > messed with it's arguments and so even this first argument will not fit in
> > interval from arg_start to arg_end. IMO we do not need "Windows way" (to put
> > bug back just to make programs happy; since expansion of command line was
> > done over environment such solutions can not be called even remotely "sane"
> > anyway). But we can (and IMNSHO should!) make "proper" implementation of
> > setproctitle(3) in glibc instead: too many important programs using it.
> > We need some support in kernel though. I cooked up patch (see below). There
> > are two new syscalls: setenviron(2) and setarguments(2). One for use in
> > setenv(3)/unsetenv(3) and one for setproctitle(3).
>
> Why do you need extra syscalls? What is wrong with procfs simply reading
> argv[0] and printing the string that currently points to?
Because it is quite likely you'll have to page in the first page of
the process stack, just for ps. That's pretty silly. ps is already
intrusive enough - we should be spending time on making sure ps
is more efficient, not less.
The performance hit when running top or ps during serious database
workloads is significant (20% or higher in 2.2 kernels!).
>
> Then a program can implement setproctitle(3) by simply changing argv[0],
> and setting argv[1] to 0.
Blech. ps/procfs has no business poking around in the address space of another
process. If you absolutely _must_ have ps showing the state of some
process, then construct a new non-standard system call.
Once multiple page size support for apps is available, it will be a given
that the location of argv[0] will _not_ be fixed (at least between
page sizes), now you've added additional special case code to ps and/or procfs
whenever the kernel supports additional page sizes (like on mips,
ia64, et. al).
For the most part, e.g. innd, sendmail, there are other ways to determine
the current status (ctlinnd, mailq) of the process, and such is as it
should be.
scott
>
> -- Jamie
>
>
-
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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:22 EST