2009/7/26 Denys Vlasenko <[email protected]>: > On Saturday 25 July 2009 11:07, Alexander Shishkin wrote: >> 2009/7/25 Denys Vlasenko <[email protected]>: >> > 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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
