AW: why are init's arguments wiped ?

Laurent Bercot ska-dietlibc at skarnet.org
Mon Feb 1 10:55:32 UTC 2016


On 01/02/2016 08:12, 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


More information about the busybox mailing list