From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 14:51:16 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8B6A16A4BF for ; Sat, 13 Sep 2003 14:51:16 -0700 (PDT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFF9943FA3 for ; Sat, 13 Sep 2003 14:51:15 -0700 (PDT) (envelope-from DougB@freebsd.org) Received: from 12-234-22-23.client.attbi.com ([12.234.22.23]) by comcast.net (sccrmhc13) with SMTP id <20030913215114016006r69se>; Sat, 13 Sep 2003 21:51:15 +0000 Date: Sat, 13 Sep 2003 14:51:14 -0700 (PDT) From: Doug Barton To: "M. Warner Losh" In-Reply-To: <20030913.153658.43409469.imp@bsdimp.com> Message-ID: <20030913144105.K85817@12-234-22-23.pyvrag.nggov.pbz> References: <20030912212606.3d04f3ed.refugee@vt.edu> <20030913.003350.98343503.imp@bsdimp.com> <20030913142107.V85817@12-234-22-23.pyvrag.nggov.pbz> <20030913.153658.43409469.imp@bsdimp.com> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: refugee@vt.edu cc: freebsd-current@freebsd.org Subject: Re: devd/devctl X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Sat, 13 Sep 2003 21:51:16 -0000 On Sat, 13 Sep 2003, M. Warner Losh wrote: > In message: <20030913142107.V85817@12-234-22-23.pyvrag.nggov.pbz> > Doug Barton writes: > : That functionality is being ported back to the vendor, if it hasn't been > : already. If we want really cool whizbang features that are more specific > : to us, we _should_ be looking at stuff like devd. The trick is definig > : which problem space we're addressing at any given moment. :) > > You can't do it in devd. You must be able to either (a) tell a > running dhclient about arrival/departures of interfaces Ok, maybe I misunderstand, but wouldn't _this_ be the right thing for devd to do? In other words, devd should be able to notice this, and devd.conf should be able to define what I want to do with this like sending a signal to dhclient. Then we can move to the dhclient problem space, and define behavior in dhclient that says "when X happens, I need to do Y." One way to do this would be to define multiple interfaces in dhclient.conf, and add an "optional" flag to each interface stanza. Then when dhclient receives a signal, it rescans the list of interfaces it knows about looking for link. This is just a conceptual example of course, other solutions might well be possible. > or (b) run multiple dhclients. This is evil, and basically undoable with the current state of things, but it might be possible down the road, although I still think it's evil for other reasons. Doug -- This .signature sanitized for your protection