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

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 <[email protected]>:

> On 01/02/2016 08:12, [email protected] 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
> [email protected]
> http://lists.busybox.net/mailman/listinfo/busybox
>
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to