On 01/02/2016 08:12, dietmar.schind...@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@busybox.net http://lists.busybox.net/mailman/listinfo/busybox