Overhaul dhcpcd for chrome os use

Overhaul dhcpcd for chrome os use:
- merge dbus support
- remove direct configuration of system resources; instead signal flimflam via dbus
- add breakpad support
- add python test scripts
- rename dbus service name to org.chromium.dhcpcd to avoid confusion

TEST=collect dhcp leases from a variety of servers and monitor dbus msgs; replace dhclient w/ flimflam and test wired, wireless, and 3g operation (verify lease contents are properly configured by flimflam)
BUG=574
Note: requires separate changes for flimflam and ebuild glue

[Sam Leffler, 2010-06-02 21:05:32]

Pushing this now to get review started.  Still need to resolve flimflam ->
dhcpcd communication (e.g. to renew lease) but even w/o that dhcpcd is usable as
a replacement for dhclient if we restart it as we do dhclient.

[Eric Shienbrood, 2010-06-03 22:50:07]

I assume you considered keeping the configuration code so that dhcpcd could also
still be used in the normal way, and we could get rid of dhclient. Was this just
too hard to do?

http://codereview.chromium.org/2428004/diff/1/2
File Makefile (right):

http://codereview.chromium.org/2428004/diff/1/2#newcode16
Makefile:16: _DBUSCFLAGS!=	${_DBUSCFLAGS_SH}
I thought I knew make pretty well, but I've never seen the != construct.

http://codereview.chromium.org/2428004/diff/1/24
File eloop.c (right):

http://codereview.chromium.org/2428004/diff/1/24#newcode378
eloop.c:378: if (e->flags) {
It may amount to the same thing, but wouldn't it be better to do "if
(e->callback_f)" instead of "if (e->flags)"?

http://codereview.chromium.org/2428004/diff/1/27
File net.c (right):

http://codereview.chromium.org/2428004/diff/1/27#newcode468
net.c:468: return ifr.ifr_mtu;
Looks like this code just moved, but is unchanged. Is there any reason to
include this in the checkin?

[Sam Leffler, 2010-06-03 23:15:15]

> I assume you considered keeping the configuration code so that dhcpcd could
also still be used in the normal way, and we could get rid of dhclient. Was this
just too hard to do?

Yes, I initially tried to preserve the functionality but took this route because
it simplified the code (e.g. allowed me to dump all the hooks stuff) and also
because I really want to disallow privileged work in dhcpcd.  (I still haven't
completed the latter--I need to drop root privs and sandbox the process once
it's got the raw socket open.)

I agree having two apps is confusing but it's only for test and developers who I
think can cope.  Am open to redoing this though.

http://codereview.chromium.org/2428004/diff/1/2
File Makefile (right):

http://codereview.chromium.org/2428004/diff/1/2#newcode16
Makefile:16: _DBUSCFLAGS!=	${_DBUSCFLAGS_SH}
FWIW it's taken from the dhcpcd-dbus Makefile.

http://codereview.chromium.org/2428004/diff/1/24
File eloop.c (right):

http://codereview.chromium.org/2428004/diff/1/24#newcode378
eloop.c:378: if (e->flags) {
I agree it is better. However this is the upstream code unchanged (I took the
more general eloop.c support from dhcpcd-dbus in order to satisfy it's needs).

Do you want me to alter it?

http://codereview.chromium.org/2428004/diff/1/27
File net.c (right):

http://codereview.chromium.org/2428004/diff/1/27#newcode468
net.c:468: return ifr.ifr_mtu;
Not sure how it got there; will move it back to reduce diffs.

[Eric Shienbrood, 2010-06-08 15:04:34]

LGTM

http://codereview.chromium.org/2428004/diff/1/24
File eloop.c (right):

http://codereview.chromium.org/2428004/diff/1/24#newcode378
eloop.c:378: if (e->flags) {
On 2010/06/03 23:15:15, Sam Leffler wrote:
> I agree it is better. However this is the upstream code unchanged (I took the
> more general eloop.c support from dhcpcd-dbus in order to satisfy it's needs).
> 
> Do you want me to alter it?

Nah, it's not worth it. I didn't realize it had come from upstream.