From owner-freebsd-usb@FreeBSD.ORG Tue Mar 3 01:16:06 2009 Return-Path: Delivered-To: usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA8FC106564A; Tue, 3 Mar 2009 01:16:06 +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 989D48FC18; Tue, 3 Mar 2009 01:16:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n231Evjv034905; Mon, 2 Mar 2009 18:14:57 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 02 Mar 2009 18:15:13 -0700 (MST) Message-Id: <20090302.181513.1973603215.imp@bsdimp.com> To: andrew-freebsd@areilly.bpc-users.org From: "M. Warner Losh" In-Reply-To: <20090302233215.GA53763@duncan.reilly.home> References: <2fd864e0903020512i22b2c31fg487aaf37fed6398b@mail.gmail.com> <20090302.132522.-432836388.imp@bsdimp.com> <20090302233215.GA53763@duncan.reilly.home> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: usb@freebsd.org, yanefbsd@gmail.com, mmakonnen@gmail.com, freebsd-current@freebsd.org, astrodog@gmail.com Subject: Re: The rc.d mess strikes back X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 01:16:07 -0000 In message: <20090302233215.GA53763@duncan.reilly.home> Andrew Reilly writes: : On Mon, Mar 02, 2009 at 01:25:22PM -0700, M. Warner Losh wrote: : > In message: <2fd864e0903020512i22b2c31fg487aaf37fed6398b@mail.gmail.com> : > Astrodog writes: : > : As unfortunate (and annoying) as that delay was, your system was in a : > : "defined" state, at the end of rc.d. As things stand now, that doesn't : > : appear to be the case anymore, and I think that may be a more : > : significant issue than the delay. : > : > I'd be happy with synchronous dhcp. : : The more general problem is the (large) number of network : applications that assume that network addresses and routes never : change (because that's how things were when they were written.) : My personal pet peeve is ntpd, but there are many others. Any : daemon that caches host IP address information at startup is : (IMO) broken, and needs to be fixed. There are many reasons why : network addresses may change *after* startup, and it is not : reasonable to go around and manually HUP everything when that : happens. True. : Needing synchronous DHCP as a work-around here is just the : signifier of the problem: it isn't the over-all solution. It is a short-term work-around at best. Warner