AW: why are init's arguments wiped ?

[Tito]

On 02/01/2016 01:29 PM, Nicolas CARRIER wrote:
> "/proc/1/cmdline is not a standard Unix ..."
>
> I absolutely don't know any other OS, be it Unix or not... But don't
> they provide a way to access the command-line used to launch a program ?
> In busybox's code at least, I see only one implementation of
> read_cmdline, which reads the content of /proc/[PID]/cmdline.
>  From that I conclude that only Unices having this file can have a
> busybox ps implementation dealing with the command-line.
>
> What's more, I don't think that erasing it's command-line is a "nice"
> behavior for a program.
> What if I want to debug how init was launched ? The way it behaves now
> makes it impossible to know if a runlevel has been passed, how it was
> passed, or even if we are launching the right init binary.
> On some platforms I work on, there are 2 different init binaries, it
> would be nice if performing a simple ps could assure me the right init
> binary is used.

Hi,
is renaming them to init1 and init2 an option?

Ciao,
Tito

> To conclude, I don't think that "allow[ing] init to take arguments" is
> only useful for "passing of information in the init arguments via
> /proc/1/cmdline". It is also a way to preserve informations passed by
> init's father, whose motivations we can't foresee.
>
> 2016-02-01 11:55 GMT+01:00 Laurent Bercot <ska-dietlibc at skarnet.org
> <mailto:ska-dietlibc at skarnet.org>>:
>
>     On 01/02/2016 08:12, dietmar.schindler at manroland-web.com
>     <mailto:dietmar.schindler at manroland-web.com> wrote:
>
>         Anyone doing engineering work should come up with a better reason
>         than something like "that's always been done that way".
>
>
>       Oh, definitely. But I'm not the one engineering something here,
>     I'm the bad guy saying I don't like the suggested change.
>
>       History and tradition *are* valid objections to change, because
>     breaking
>     compatibility (if only compatibility of visual output) has a cost.
>     They're not powerful objections: if a historical design is bad, and
>     the new design brings obvious benefits, then it's entirely worth
>     deviating
>     from tradition. But everything else being equal, if the new design isn't
>     strictly more powerful than the old one, then tradition may be worth
>     keeping.
>
>       In the present case, the choice is between "wipe init arguments"
>     (historical) and "allow init to take arguments" (suggested change).
>        Advantages of the historical behaviour: clean ps output
>        Advantages of the suggested change: passing of information in the
>     init arguments via /proc/1/cmdline
>
>       Given that /proc/1/cmdline is not a standard Unix way of passing
>     information, and that the OP's program would thus *only* work with
>     the new-and-modified busybox init under Linux, making this change
>     nothing more than a hack;
>       Given that Unix already provides plenty of ways to pass information
>     from a process to its scions, and that the command line is only such
>     a way for programs specifically designed to perform chain loading,
>     which init is not;
>       Given that I have suggested an *easy*, safe, portable and perfectly
>     Unix-ish way of accomplishing what the OP wants without having to patch
>     anything;
>       Therefore, in this precise case, I don't think the change is worth it.
>
>       Seriously. Accusing *me* of following historical behaviours for the
>     sake of it. :D
>
>     --
>       Laurent
>
>     _______________________________________________
>     busybox mailing list
>     busybox at busybox.net <mailto:busybox at busybox.net>
>     http://lists.busybox.net/mailman/listinfo/busybox
>
>
>
>
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>