Date: Fri, 19 Mar 2004 15:33:29 +0300 From: Gleb Smirnoff <glebius@cell.sick.ru> To: Harti Brandt <brandt@fokus.fraunhofer.de> Cc: freebsd-net@freebsd.org Subject: Re: Nodes having common properties. Was: kern/63864: [patch] new control message for ng_iface(4) - getifindex Message-ID: <20040319123329.GA39103@cell.sick.ru> In-Reply-To: <20040319115814.E41950@beagle.fokus.fraunhofer.de> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040319123329.GA39103>