AW: why are init's arguments wiped ?

[Nicolas CARRIER]

I was talking in general, to illustrate the fact that abandoning
information is not a good thing.
In my situation, things will work eventually, because our other init
process doesn't alter it's arguments.

2016-02-01 14:13 GMT+01:00 Tito <farmatito at tiscali.it>:

>
>
> 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
>>
>> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20160201/e39534c8/attachment-0001.html>