Date: Tue, 21 Aug 2012 11:36:30 -0600 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: lev@freebsd.org Cc: freebsd-current@freebsd.org Subject: Re: r239356: does it mean, that synchronous dhcp and dhcplcinet with disabled devd gone? Message-ID: <1345570590.27688.367.camel@revolution.hippie.lan> In-Reply-To: <1409150425.20120821210152@serebryakov.spb.ru> References: <20120821095527.GA33206@hell.ukr.net> <67977762.20120821154035@serebryakov.spb.ru> <1959717636.20120821155308@serebryakov.spb.ru> <201208210934.31484.jhb@freebsd.org> <1049151425.20120821190433@serebryakov.spb.ru> <1345562163.27688.347.camel@revolution.hippie.lan> <709115163.20120821192652@serebryakov.spb.ru> <1345564507.27688.354.camel@revolution.hippie.lan> <1409150425.20120821210152@serebryakov.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2012-08-21 at 21:01 +0400, Lev Serebryakov wrote: > IL> The important point is that if you unplug the cable then plug it into a > IL> different network, now the right thing will happen -- you will acquire > IL> an address on the new network. That's the reason that this change is an > IL> important bugfix for a long standing (many many years) bug in freebsd's > IL> dhclient. > No, I'll be without dhclient at all, if I don't use devd :(. And > absence of devd is completely legal, and should be supported. It is > perfectly valid and sensible setup for small devices (think: > MIPS-based routers, which are started to be supported now), where devd > could be very costly in both terms of flash size (it is C++ > application and need C++ runtime!) and memory (only devd event on > such devices are this cable plugging/unplugging -- so using devd > doesn't add any value for such setups). > I think it's funny how people have this knee-jerk reaction against C++ apps. The devd executable is not exactly an example of bloatware: 374k statically linked (so it already includes this "C++ runtime" that you think is large). We routinely deploy embedded systems that use apps written exclusively in C++, on systems that only have 32 or 64mb of ram. We've been doing so since the days when the biggest compact flash card you could buy was 64mb. Perhaps the right solution is to add a dhclient command line option to operate in the historical buggy mode: it doesn't exit on link status changes, and fails to work properly if those link status changes are happening because the physical connection has moved to another network. If so, I think the default should be to work correctly, and folks depending on the historical buggy behavior will have to add a parm to rc.conf. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1345570590.27688.367.camel>