On 29/01/2016 17:50, Nicolas CARRIER wrote:
I quite agree with dietmar, concerning uglyness...
<shrug> That doesn't change the fact that it's the behaviour of every init binary since 1970 and that you should come with a better reason if you want to change it, especially since it's so easy to accomplish what you want with a little workaround.
And concerning the replacement of init with a script, well, hum... :D Is it even possible ?
It is very possible, and a lot of init systems do this. If you are using a distribution that comes with an initramfs, you are using this feature every time you boot.
Won't it suffer from the lack of proc / sys and dev ? Environment variables setup by init ?
This does not matter if all you want is to get command-line arguments and store them somewhere (in the environment, for instance).
What's more, there is a risk to spawn multiple processes (eval ?) before init is launched and the previous questions do apply.
No risk. The only important thing is to make sure your pid 1 does not die, and eventually execs into init. Your zombies will all be reaped when init starts.
In the meantime, I find it rather strange that busybox wipes it's arguments, knowing that passing arguments to init is a feature supported, at least, by linux and that only argv[1] is parsed, so extra arguments would do no harm. The ps argument is quite strange, why does it matter ? "Cluttered" command-lines are quite well accepted for other processes, why would init be any different ?
Because it's a convention that init prints "init" and nothing else (or sometimes its default runlevel) in the process list. Also, the fact that nothing under init actually uses the arguments to init, so it should not matter at all. Using /proc/1/cmdline to get those arguments is very ad hoc ; this is not a POSIX way to transmit information to other programs, and init is free to not support it. -- Laurent _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
