Date: Fri, 19 Mar 2004 14:24:47 +0100 (CET) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: Gleb Smirnoff <glebius@cell.sick.ru> 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: <20040319141700.J42356@beagle.fokus.fraunhofer.de> In-Reply-To: <20040319123329.GA39103@cell.sick.ru> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040319141700.J42356>