Date: Sun, 30 Nov 2003 19:42:20 +0000 From: Bruce M Simpson <bms@spc.org> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: ifconfig(8) refactoring -- YACC grammar now online Message-ID: <20031130194220.GB36456@saboteur.dek.spc.org> In-Reply-To: <Pine.NEB.3.96L.1031130141754.66375V-100000@fledge.watson.org> References: <20031130135805.GA80639@saboteur.dek.spc.org> <Pine.NEB.3.96L.1031130141754.66375V-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031130194220.GB36456>