[PATCH] halt: add option to call telinit when using external init

[Alexander Shishkin]

2009/7/26 Denys Vlasenko <vda.linux at googlemail.com>:
> On Saturday 25 July 2009 11:07, Alexander Shishkin wrote:
>> 2009/7/25 Denys Vlasenko <vda.linux at googlemail.com>:
>> > On Tuesday 21 July 2009 23:31, Alexander Shishkin wrote:
>> >> In case our init is not a busybox applet, but an external program
>> >> like SysV init or upstart, we'd want to be able to call telinit
>> >> (or somesuch) to switch to an appropriate runlevel instead of
>> >> simply rebooting (or otherwise shutting down).
>> >
>> > I am torn on this.
>> >
>> > Can't it be achieved much simpler, e.g.
>> >
>> > /bin/reboot:
>> >
>> > #!/bin/sh
>> > test x"$1" = x"-f" && /bin/busybox reboot "$@"
>> > exec telinit 6
>> >
>> > ?
>>
>> Of course it could, but let's see: we compile busybox with halt
>> applets,
>
> ... because we want to be able to do "reboot -f". For example,
> for me it's the only "standard" way to hard reboot the machine
> from my shutdown script which I use instead of "reboot without -f"...
>
> reboot -f is the only action of reboot which can't be implemented
> via shell.
And this is why "reboot -f" functionality is left intact by the patch proposed.

>> then we manually replace reboot/poweroff symlinks with crude
>> shell hacks
>
> "crude" and "hacks" is an emotional attiture, its not technical.
> "We replace reboot/poweroff symlinks with shell scripts", yes.
> Let's see whether this is good or bad...
Those are largely interchangeable, but that's a matter of opinion.

> I do not reject patches because I want people to suffer.
> I try to incorporate patches even if I do not 100% agree with them.
> But if I am seriously unsure, then I discuss them, expaining
> why they do not look ok to me.
About time we get to that explaining part.

>
>> Come to think of it, 9/10 of busybox functionality could be
>> implemented in shell,
>
> And some of it definitely should have been. ifup is a candidate #1.
> reboot also can be. An applet which does nothing else than starts
> or signals other processes and neither runs for a long time (server)
> nor contains complex logic, isn't really something which
> is best written in C.
I completely miss the point here. If it is already implemented in C,
working and maintainable, why would anyone want to replace it with
something scripted? If I have to reboot and especially "reboot -f",
I'm very likely to be on a tight schedule and not have time to fork
off a shell and have it interpret a script. There are also context
switches, which are costly on some architectures. Same stands for
ifup, which, be it a shell script will eat into my system's bootup
time where every millisecond is valuable (I'm not talking about
desktop machines).

> I do not plan to remove such applets, but will need a very good
> rationale why it's good to add _more_ things like these.
Because one might want things to be small and fast when one considers
using busybox.

>> however, it's not and having a trivial patch in
>> is actually loads simpler than having to maintain half arsed scripts
>> that try to deal with command line options for applets.
>> Which reminds me, btw, why is this not done the same _simpler_ way you
>> suggest for the -i option of reboot?
>
> You need to bring technical arguments, not emotional ones.
> I think this is not an unreasonable request from my side.
-i bit is not an argument, but a question.

> Technically speaking, the situation is like this:
>
> bbox reboot currently is meant to work with busybox init.
I don't know where this comes from, but _technically_ (considering
init/Config.in and the actual code) nothing says that.
And even should that be the case, I don't see the point.

> You propose to make it possible to use it with SysV init
> (and any other kinds which have telinit), right?
Right. There is little point in using it with SysV init though which,
as you pointed out, has its own reboot/poweroff.

> Since you are using SysV init, doesn't it make more sense
> to use _corresponding_ reboot from the same package?
> I think SysV init provides those. Correct me if I'm wrong.
I'm not, I'm using upstart, which in its present semiexperimental
state does not provide means of rebooting. And I hear there are other
"better" init replacements in the making.

> Do you think it's beneficial for bbox to be able to mimic
> SysVinit's reboot and it outweighs the additional of a CONFIG_xxx
> and increased chances of users being confused?
Well, my opinion here is that if you can make a busybox applet behave
in as many [real life, might I add] situations as possible at low
cost, then do it. Additional CONFIG_ options are cheap, all things
considered. Chance of user getting confused is at absolute minimum: he
won't even be offered to select these options unless he has HALT
enabled and INIT disabled, in which case he might be interested in
these options.

Regards,
--
Alex