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-dietl...@skarnet.org <mailto:ska-dietl...@skarnet.org>>: On 01/02/2016 08:12, dietmar.schind...@manroland-web.com <mailto: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 <mailto:busybox@busybox.net> http://lists.busybox.net/mailman/listinfo/busybox _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
_______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
