From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 14:30:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBBD81065670; Wed, 15 Sep 2010 14:30:51 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E967E8FC13; Wed, 15 Sep 2010 14:30:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o8FEP7fb088627; Wed, 15 Sep 2010 08:25:07 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 15 Sep 2010 08:25:13 -0600 (MDT) Message-Id: <20100915.082513.802140508206832836.imp@bsdimp.com> To: demelier.david@gmail.com From: "M. Warner Losh" In-Reply-To: References: <20100910234830.87641e07.ray@ddteam.net> <4C8ACE52.8060000@FreeBSD.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: kimelto@gmail.com, ray@ddteam.net, dougb@freebsd.org, mj@feral.com, freebsd-current@freebsd.org Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 14:30:51 -0000 In message: David DEMELIER writes: : 2010/9/11 Doug Barton : : > On 9/10/2010 1:48 PM, Aleksandr Rybalko wrote: : >> : >> Hi, : >> : >> another argument about hostapd :) if have access point we must have : >> way to assign IP for AP clients. : > : > To start with, your assumption is wrong. DHCPd is not *actually* a : > requirement, although I admit that practically it is. : > : >> Last spring I made firmware based on FreeBSD for router with only 4MB : >> NOR flash (D-Link DIR-320). : > : > In this category (micro-miniaturization) you're already in the "significant : > customization needed" area, which means that general arguments about "the : > base" don't apply. : > : >> Since this device is router I must be : >> able to serve DHCP. And current implementation of dhcpclient, that we : >> have, is same isc-dhcp, and I replace system dhcpclient with ports : >> one+dhcpd but with small patch that put basic dhcp utils onto : >> libdhcp.so. : > : > Your argument is creative and well thought out, but I personally don't find : > it persuasive. Counter arguments that come immediately to mind are: : > 1. The DHCP server is not going to benefit any but a small minority of : > FreeBSD users. : > 2. The software is already available in the ports tree, and adding a : > port/package of it really is not an overwhelming burden. : > : > More generally, the main reason I want to keep more stuff out of the base, : > and remove some of the stuff that's in there now, is that it makes : > maintenance difficult across FreeBSD branches. We have a general policy that : > if we have a major version N of something in a release branch that we don't : > upgrade that major version without a really good reason to avoid POLA : > surprises for our users. Once again using BIND as an example, this has led : > to a really old and past-EOL version of BIND in FreeBSD 6 which I've only : > gotten away with because anyone doing serious DNS work nowadays has to : > upgrade to at least 9.6 anyway. But it's an ugly situation, and I don't want : > to repeat it. : > : : I agree but like Aleksandr said, almost 70% of dhcp code is already in : base so adding 1Mb of dhcpd code wouldn't be too much. I like the idea : to keep some parts in the ports tree and move out from the base. Yea. I agree too. Just because BIND was EOLd in 6 isn't a great argument against dhcp server. Most of the code is there anyway, and it isn't evolving as fast as BIND. It would be very convenient to have this particular thing in the base, and we shouldn't be too dogmatic about never having any new 3rd party things in the base. After all, we just added more compression utilities to the base, and nobody said a peep. This is analogous: we have good opportunity to integrate into the system, and users benefit from that integration. Warner