Re: If something is not stated in POSIX we should not bother even if 90%+ of Linux system out there using it ??

From: Khimenko Victor (khim@dell.sch57.msk.ru)
Date: Mon Mar 06 2000 - 19:39:56 EST


On Tue, 7 Mar 2000, Jamie Lokier wrote:

> Khimenko Victor wrote:
>
> > 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?
>
What about argvc ?

> Then a program can implement setproctitle(3) by simply changing argv[0],
> and setting argv[1] to 0.
>
Yes, we can replace one hack (used in 2.2) with another one (you just
described) and change kernel so this second hack will work. My point is
simple: if we need to change kernel at all then why not implement proper
solution ? If program want to change argument list or environment list
then why notallow to do exactly this ? Why we should cut tonsils over
asshole ? Why not do it straight ? There are exist functions to change
environment list and arguments list (setenv, putenv, setproctitle; putenv
is even POSIX AFAIK). But when you are using those functions NOTHING is
changing in /proc/<number>/cmdline and /proc/<numeber>/environ or changing
in strange, really strange way. IMHO it can be called error. Yes, not
exactly kernel error, rather glibc error. Just one small thing: you CAN
NOT fix that error from userspace without changes in kernel.

-
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 : Tue Mar 07 2000 - 21:00:21 EST