PATCH: ifupdown.c, udhcpc, and standalone shell

Eric Spakman E.Spakman at inter.nl.net
Wed Sep 27 15:39:42 UTC 2006


Denis,

<snip>
>>>> Since udhcpc is an option provided by busybox itself, I think it
>>>> should be the first one we try to run. If we want a more complex
>>>> setup (i.e., don't compile the udhcpc applet into busybox, and
>>>> supply our own binary) then we should accept to put up with
>>>> error/warning messages as ifup searches for the correct dhcp client.
>>>>
>>>>
>>>> I've attached the modified ifupdown.c.gz.
>>>>
>>>>
>> Why should we accept to put up with error/warnings messages, it didn't
>> generate those messages with the previous version. Personally I don't
>> think this is an improvent.
>
> Hmm.. In my personal opinion whole idea behind ifup is stupid.
> Executables should not decide which commands to run, it should
> be scriptable. As I said, I use runit - which is.
>
Agree for the hardcoded executable part, for the rest ifupdown is a nice
high level config system. Especially because it supports "plugin" scripts
to extend its functionality (if-up.d/if-down.d/...)

> But I am not trying to change whole world, if there are users
> for ifup, okay, will try to make it work.
>
> How do you propose to cleanly check that execute("foo bar baz");
> will be able to find and execute foo executable - without actually trying
> to execute it? "if /sbin/foo exists" is not a good check. --

The version of ifupdown before this patch didn't generate error messages
(AFAIK, at least I never saw them). The reason for this patch is to make
it work with CONFIG_FEATURE_SH_STANDALONE_SHELL. Isn't it possible to just
remove the paths from the calls and rely on the environment?

I know this isn't an answer on your question...

> vda
>
Eric




More information about the busybox mailing list