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