From owner-freebsd-rc@FreeBSD.ORG Mon Jun 1 22:32:01 2009 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD4041065679 for ; Mon, 1 Jun 2009 22:32:01 +0000 (UTC) (envelope-from dougb@dougbarton.us) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 872588FC14 for ; Mon, 1 Jun 2009 22:31:59 +0000 (UTC) (envelope-from dougb@dougbarton.us) Received: (qmail 6348 invoked by uid 399); 1 Jun 2009 22:31:56 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 1 Jun 2009 22:31:56 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A2456DA.8040104@dougbarton.us> Date: Mon, 01 Jun 2009 15:31:54 -0700 From: Doug Barton User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: Brooks Davis References: <4A21A4F6.5060709@dougbarton.us> <20090601212506.GA2351@lor.one-eyed-alien.net> In-Reply-To: <20090601212506.GA2351@lor.one-eyed-alien.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org Subject: Re: Removal of deprecation for network_interfaces != AUTO X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 22:32:02 -0000 Brooks Davis wrote: > On Sat, May 30, 2009 at 02:28:22PM -0700, Doug Barton wrote: >> Without objection I plan to commit the attached patch before the code >> slush, and to MFC the change. > > I object. Supporting values other than AUTO adds unnecessary > complexity (not a lot, but some) and IMO leads to difficulty diagnosing > proper system behavior. Can you provide examples? I've seen this argument before, but I seriously fail to understand it. The code to generate the list for AUTO is trivial, and I've never seen a support question that was caused by setting this to a different value. > I'd much rather just delete network_interfaces entirely. > > I've never seen a valid use case, just failures to understand the > current system. One could argue that the current system needs better documentation which should cover at least half that problem. Meanwhile, I've objected to the original change several times, as have various other users. After I committed the change BMS responded to my message on the svn list to say that he is planning on using this feature for a product that is currently in development as well. >> I've never seen the rationale for this, and I use a value other than >> AUTO personally for a script I have that tests to see if the wired >> interface is up and starts the wireless if not. I've also seen other >> users ask about this from time to time, so I'm sure I'm not alone. > > Please provide this script to support your argument. I set the value of network_interfaces to "lo0 test" and then I have a /etc/start_if.test script that checks to see if my wired interface is up, initializes it if it is, and if not it checks to see which wireless card I'm using and initializes that. I've actually spent quite a lot of time trying to figure out how to accomplish something similar with the current system but AFAICS we don't have a way to do that without hooking it in at the point where the network interfaces are actually configured. At some point in the future when I get a whole bunch of free time I'd like to extend what's in the base in order to do what I'm doing now with my little script ... Doug