lkml.org 
[lkml]   [2000]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Does anybody try to compile the 2.3 kernels at all ? :((
On Thu, 10 Feb 2000, Richard B. Johnson wrote:

> On Fri, 11 Feb 2000, Sergey Kubushin wrote:
>
> [SNIPPED <fire and ice>]
>
> > But I wanna know what lies behind the changed /proc/*/cmdline.
>
> Read "the list". It's being worked on. I was one of the persons that
> discovered the change. The guy that's working on it says he's going
> to make it possible to read new pointers rather than just old data
> space.
>
> This means that:
>
> strcpy(argv[0], "Overwrite the command line and environment");
> .. which is dangerous... Will eventually allow:
>
> argv[0] = "New string of whatever length you want";
>
> This allows backwards compatibility as well as forwards. Right now,
> if you have a copy of your `init` source, just do:
>
>
> char tmp_buf0[0x08]; /* Room for "init" */
> char tmp_buf1[0x08]; /* Room for "auto" */
>
> strcpy(tmp_buf0, argv[0]);
> strcpy(tmp_buf1, argv[1]);
>
> argv[0] = (char *) malloc(0x100);
> argv[1] = (char *) malloc(0x100);
> strcpy(argv[0], tmp_buf0);
> strcpy(argv[1], tmp_buf1);
>
> This makes lots of room for future children so you don't have to
> modify any of them.

Unfortunately it does NOT work. /proc/*/cmdline does contain the _ORIGINAL_
argv. If you substitute argv with something in your main(), you'll see only
original argv contents in /proc/*/cmdline. ALL your changes to the new argv
go to /dev/null, kernel remembers only the original argv. So if you're
modifying the original argv[0], you see it circumsized down to the original
allocated size. If you substitute it with anything else, you see only the
original argv[0], kernel is unaware of your substitution.
So I'd like to ask does anybody recall who did change the usual behaviour?
What was a reason in breaking what worked in 1.2, 2.0 and 2.2 ? It looks
like nobody does remember neither who did it nor for a what reason. Why did
we break the whole bunch of decent daemons? What did we gain? Are we to be
ahead of _ALL_ Unices in that of impossibility to have something like
working setproctitle()? AFAIK, there is no another Unix out there which does
not allow decent daemon to change it's title shown in ps output. Except
upcoming shiny new 2.4 Linux, of course. Are _ALL_ the Unices wrong? Does
anybody care?

Sorry for telling this, but it looks like core kernel developers live in an
ivory tower and did lost any connection to the real world... It seems that
2.3 is developed for the sake of a pure art which does not need to have any
practical value, only aestetic one... And that 2.3 kernel is not just a
moving target, it's moving accordingly with a rule of Brown...

===========================================================================
Sergey Kubushin aka the Tamer < > The impossible we do immediately.
e-mail: ksi@ksi-linux.com SK320-RIPE < > Miracles require 24-hour notice.
===========================================================================

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site