why are init's arguments wiped ?
Isaac Dunham
ibid.ag at gmail.com
Fri Jan 29 16:32:43 UTC 2016
On Fri, Jan 29, 2016 at 08:27:19AM +0100, Nicolas CARRIER wrote:
> Thank you for your answer.
>
> Even if I'm using linux, I want the solution to work in the context of init
> being launched as a pid 1 of a pid namespace, which is my main use case.
> In this situation, the kernel's command line can't be changed as it's the
> one of the host PC.
>
> Luckily enough, I have several ways to achieve what I want, but in my
> opinion, using init's arguments would have been the most elegant option.
>
> I'm really interested in knowing which is the real reason behind this
> feature and if there is any chance that a patch would be accepted, to
> either remove, or allow to disable this part of the code.
A patch to optionally disable a feature is usually acceptable, it seems.
I can't speak for the maintainer, though.
However, I seem to recall that commonly, options like 'foo=bar' get into
the environment.
This would be doable by means of a script that execs busybox init,
something like this (untested, doesn't handle -...):
for opt in $#; do
case "$opt" in
(*=*) eval "$opt"
;;
esac
done
exec busybox init $@
HTH,
Isaac Dunham
More information about the busybox
mailing list