Messages in this thread | | | Date | Tue, 7 Mar 2000 03:39:56 +0300 (MSK) | From | Khimenko Victor <> | Subject | Re: If something is not stated in POSIX we should not bother even if 90%+ of Linux system out there using it ?? |
| |
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/
| |