From owner-freebsd-net@FreeBSD.ORG Fri Mar 19 05:24:51 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5731816A4CE; Fri, 19 Mar 2004 05:24:51 -0800 (PST) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id C45D443D2F; Fri, 19 Mar 2004 05:24:49 -0800 (PST) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])i2JDOlJ10124; Fri, 19 Mar 2004 14:24:47 +0100 (MET) Date: Fri, 19 Mar 2004 14:24:47 +0100 (CET) From: Harti Brandt To: Gleb Smirnoff In-Reply-To: <20040319123329.GA39103@cell.sick.ru> Message-ID: <20040319141700.J42356@beagle.fokus.fraunhofer.de> References: <200403072302.i27N2StR008804@freefall.freebsd.org> <20040308212939.GB30394@ip.net.ua><20040309065356.GA55139@ip.net.ua> <20040316230130.GA20251@cell.sick.ru> <20040319123329.GA39103@cell.sick.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Nodes having common properties. Was: kern/63864: [patch] new control message for ng_iface(4) - getifindex X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: harti@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 13:24:51 -0000 On Fri, 19 Mar 2004, Gleb Smirnoff wrote: GS>On Fri, Mar 19, 2004 at 12:13:37PM +0100, Harti Brandt wrote: GS>H> It would be nice if it would be possible to classify a node to belong to GS>H> more than one family. I think, that the functionality provided by the GS>H> family stuff is more like the 'interface' stuff in Java. One example where GS>H> this can be used are specialisation of interface nodes. I'm about to GS>H> commit an ATM pseudo device node that will (among other uses) be very GS>H> helpful for automatic testing of the ATM stuff. As such it implements the GS>H> network interface messages (GET_IFINDEX, ...) plus common messages with GS>H> the real ATM device node (ng_atm; GET_CONFIG, GET_VCCS, ...). I think GS>H> there are other uses too. GS>H> GS>H> I see at least two ways of implementing this: GS>H> GS>H> 1) by handling the assignment to a family via a generic function, that, GS>H> for example, manages an array of family/data pairs for each node. Instead GS>H> of simply checking the family type when receiving a message you'll have GS>H> to loop around (control messages handling performance shouldn't be a GS>H> bottleneck). GS>H> GS>H> 2) making family message handling explicite instead of implicite. In GS>H> foo_rcvmsg you would have something like: GS>H> GS>H> switch (cookie) { GS>H> GS>H> ... GS>H> GS>H> case NGM_IFACE_FAMILY_COOKIE: GS>H> ng_handle_iface_family_msg(...); GS>H> break; GS>H> GS>H> case NGM_ATMIFACE_FAMILY_COOKIE: GS>H> ng_handle_atmiface_family_msg(...); GS>H> break; GS>H> GS>H> ... GS>H> } GS>H> GS>H> The 2nd variant seems slightly more easy to implement and more flexible GS>H> than the first. GS> GS> The 2nd variant seems very familiar (may be even same) as my first GS>proposal. In private discussion with Ruslan, he said that this approach GS>looks like a hack, and is not extendible. And he convinced me. Really, GS>this approach means that message handlers are in the ng_foo.c files, and GS>joining family doesn't mean automagic support of family messages. Also, GS>it leads to code dublication, which is bad. GS> GS> I'd prefer first idea. In its case all you need to support family GS>messages, is to call two methods GS> GS> NG_JOIN_FAMILY(NG_FAMILY_ATM, (void *)some_atm_data); GS> NG_JOIN_FAMILY(NG_FAMILY_IFACE, (void *)priv->ifp); GS> GS> from your constructor method. Family messages must be supported by GS>netgraph, not by nodes. >From the point of code duplication and extendibility both approaches are equivalent. In the second case you have the same three lines in the rcvmsg function of every node that supports a given familiy (this is reduceable to 1 line by defining appropriate macros), in the first one you have the same line in every constructor. Perhaps I made not clear that the message handling function for the familiy is not in the node's code nor in the netgraph base code, but in a family file (in both cases) and module. But I have no strong opinion: either way does it as long as it allows multiple interfaces to a given node. harti