Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Sep 2010 09:28:49 -0600 (MDT)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        dougb@FreeBSD.org
Cc:        freebsd-current@FreeBSD.org
Subject:   Re: DHCP server in base
Message-ID:  <20100917.092849.584158775148072316.imp@bsdimp.com>
In-Reply-To: <4C91100C.5060502@FreeBSD.org>
References:  <AANLkTinkJ182=GFTdWW_0OAT6rfoRJPBxnzMyukCeYnR@mail.gmail.com> <20100915.082513.802140508206832836.imp@bsdimp.com> <4C91100C.5060502@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <4C91100C.5060502@FreeBSD.org>
            Doug Barton <dougb@FreeBSD.org> writes:
: > Most of the code is there anyway, and it isn't evolving as fast as
: > BIND.
: 
: That is actually a more rational argument, even if I don't agree with
: it. FWIW, part of the reason that I don't agree with it is that at
: some point, hopefully in the near future, we will want to include the
: DHCPv6 client in the mix somewhere; and when we do the code base is
: not going to be as stable as we have enjoyed so far with the v4
: dhclient.

True, but that still won't change the dynamic that adding a dhcp
server is easy give we have most of one already in the tree.  Adding
v6 support likely will mean a certain amount of code churn, I'll grant
you that.  But the code/api churn that's happening is within a single
program, making it much easier to MFC as necessary to keep up.

: > This is analogous: we
: > have good opportunity to integrate into the system, and users benefit
: > from that integration.
: 
: Given your perspective of wanting more of a complete system in the
: base I can certainly see how you would be supportive of this
: change. My intent was to make the argument in a general way that this
: is the wrong direction to go, and that users would benefit *more* from
: a robust modularized system. The fact that the v4 DHCPd might
: accidentally be a good candidate for including in the base today
: doesn't mean that doing so is the right strategy for the long term.

I take a more nuanced view: we have to evaluate each proposed addition
to the system on its merits.  One of these criteria is long term
viability, but others include how useful is it to the users; how much
demand will there be; will including it make the project look good?;
will not including it make the project look bad?; etc

We'd all like to see a more modular base, but until that nut is
cracked, we have a balancing act to perform.

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100917.092849.584158775148072316.imp>