From owner-freebsd-arch@FreeBSD.ORG Sun Nov 30 14:38:42 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE0CF16A4D0; Sun, 30 Nov 2003 14:38:42 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9461A43FEC; Sun, 30 Nov 2003 14:38:35 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 7A3FA651EE; Sun, 30 Nov 2003 19:42:22 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13088-02; Sun, 30 Nov 2003 19:42:21 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [82.147.19.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id A1716651EB; Sun, 30 Nov 2003 19:42:21 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id C5E7B1C; Sun, 30 Nov 2003 19:42:20 +0000 (GMT) Date: Sun, 30 Nov 2003 19:42:20 +0000 From: Bruce M Simpson To: Robert Watson Message-ID: <20031130194220.GB36456@saboteur.dek.spc.org> Mail-Followup-To: Robert Watson , freebsd-hackers@freebsd.org, sam@freebsd.org, Andre Oppermann , freebsd-arch@freebsd.org References: <20031130135805.GA80639@saboteur.dek.spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: freebsd-hackers@freebsd.org cc: sam@freebsd.org cc: Andre Oppermann cc: freebsd-arch@freebsd.org Subject: Re: ifconfig(8) refactoring -- YACC grammar now online X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2003 22:38:42 -0000 On Sun, Nov 30, 2003 at 02:20:50PM -0500, Robert Watson wrote: > if_type seems like it will work for high level classes of interfaces, but > something more fine-grained will be required for interfaces that implement > multiple classes or subclasses (i.e., 802 generally, and also 802.11b). The idea just now is we look at if_media if we need to get specific with physical interfaces. tap would seem to be missing from my list, actually; I note it's used to provide VMware support in the absence of Netgraph, amongst other things. > Or likewise, tap interfaces might implement 802 generally, but also > if_tap-specific primitives. Do we need to probe by-name for capabilities > using interface ioctls, or return a "list" of implemented > interfaces/classes to allow things to be a bit more multidimensional? That might work well, actually -- I already added a MIB to rtsock to deal with our lack of reporting multicast group memberships, I see no reason not to add one to enumerate loaded interface classes. OTOH, for the 'could load kld' case, this falls down, until the instance is created, either through cloning or completing ifattach() for a physical interface -- but if CREATE is a separate operation this isn't a problem, it is a problem if we want to say something like this in one go:- ifconfig gif0 create tunnel 1.2.3.4 5.6.7.8 10.0.0.1 10.0.0.2 Then you do need a means for the ifconfig instance to ask gif0 if it speaks 'tunnel-ese' once it's loaded. I have to find an abstraction to comfortably deal with this stacking of properties/methods, simple polymorphism (a la Java 'implements interface') springs to mind. BMS