[BusyBox] udhp/dhcpd.c (lost/rejected) patch

[Denis Vlasenko]

On Tuesday 21 December 2004 07:48, Rob Landley wrote:
> On Monday 20 December 2004 10:53 am, Paul Fox wrote:
> >  > > Even though I've never observed udhcpd crashing, this
> >  > > patch affords the comfort of knowing that init will
> >  > > respawn udhcpd if this unlikely event does occur.
> >  >
> >  > Wouldn't it just be much easier then to start udhcpd from an init.d
> >  > style script?
> >
> > i'm surprised at the pushback being given to this trivial feature --
> 
> I have the urge to frame that statement as the busybox mission statement in a 
> nutshell.
> 
> 1) s/trivial/useless/

Sorry, but I tend to disagree here. Some people, including me,
prefer to run background processes under control of specialized tools
(google for daemontools for example). These tools work best
if controlled process does NOT daemonize itself.

This is why I added --foreground to udhcpcd.

> 2) Gnu bloatware is as big as it is because of an endless accumulation of 
> trivial features.  Busybox is a minimalist implementation.  Why does it come 
> as a suprise to you that we'd push back against a feature that, in the main 
> use case you're proposing to justify its inclusion, is more likely than not 
> to never actually trigger on any system anywhere even with a multi-million 
> unit production run?

Does my usage pattern of starting udhcpcd via supervise (from daemontools suite)
count as "main use case"? I think yes.

Actually, your argument against bloat can easily turn against yourself.
We can simply drop auto-daemonizing code from all daemons because
one can trivially daemonize any process via

#!/bin/sh
setsid "$@" >/dev/null 2>&1 </dev/null &

(Not that I actually propose dropping daemonizing code, but...)
--
vda