From owner-freebsd-net@FreeBSD.ORG Fri Mar 19 04:33:37 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 713C516A4CE; Fri, 19 Mar 2004 04:33:37 -0800 (PST) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9207943D3F; Fri, 19 Mar 2004 04:33:36 -0800 (PST) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i2JCXUQE039165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Mar 2004 15:33:31 +0300 (MSK) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i2JCXTrg039164; Fri, 19 Mar 2004 15:33:29 +0300 (MSK) Date: Fri, 19 Mar 2004 15:33:29 +0300 From: Gleb Smirnoff To: Harti Brandt Message-ID: <20040319123329.GA39103@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Harti Brandt , Ruslan Ermilov , julian@freebsd.org, archie@freebsd.org, freebsd-net@freebsd.org References: <200403072302.i27N2StR008804@freefall.freebsd.org> <20040308102033.GA66247@cell.sick.ru> <20040308212939.GB30394@ip.net.ua> <20040308214820.GA68803@cell.sick.ru> <20040309065356.GA55139@ip.net.ua> <20040309185957.GB74537@cell.sick.ru> <20040316230130.GA20251@cell.sick.ru> <20040319115814.E41950@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040319115814.E41950@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.5.6i 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 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 12:33:37 -0000 On Fri, Mar 19, 2004 at 12:13:37PM +0100, Harti Brandt wrote: H> It would be nice if it would be possible to classify a node to belong to H> more than one family. I think, that the functionality provided by the H> family stuff is more like the 'interface' stuff in Java. One example where H> this can be used are specialisation of interface nodes. I'm about to H> commit an ATM pseudo device node that will (among other uses) be very H> helpful for automatic testing of the ATM stuff. As such it implements the H> network interface messages (GET_IFINDEX, ...) plus common messages with H> the real ATM device node (ng_atm; GET_CONFIG, GET_VCCS, ...). I think H> there are other uses too. H> H> I see at least two ways of implementing this: H> H> 1) by handling the assignment to a family via a generic function, that, H> for example, manages an array of family/data pairs for each node. Instead H> of simply checking the family type when receiving a message you'll have H> to loop around (control messages handling performance shouldn't be a H> bottleneck). H> H> 2) making family message handling explicite instead of implicite. In H> foo_rcvmsg you would have something like: H> H> switch (cookie) { H> H> ... H> H> case NGM_IFACE_FAMILY_COOKIE: H> ng_handle_iface_family_msg(...); H> break; H> H> case NGM_ATMIFACE_FAMILY_COOKIE: H> ng_handle_atmiface_family_msg(...); H> break; H> H> ... H> } H> H> The 2nd variant seems slightly more easy to implement and more flexible H> than the first. The 2nd variant seems very familiar (may be even same) as my first proposal. In private discussion with Ruslan, he said that this approach looks like a hack, and is not extendible. And he convinced me. Really, this approach means that message handlers are in the ng_foo.c files, and joining family doesn't mean automagic support of family messages. Also, it leads to code dublication, which is bad. I'd prefer first idea. In its case all you need to support family messages, is to call two methods NG_JOIN_FAMILY(NG_FAMILY_ATM, (void *)some_atm_data); NG_JOIN_FAMILY(NG_FAMILY_IFACE, (void *)priv->ifp); from your constructor method. Family messages must be supported by netgraph, not by nodes. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE