Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Mar 2004 12:13:37 +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:  <20040319115814.E41950@beagle.fokus.fraunhofer.de>
In-Reply-To: <20040316230130.GA20251@cell.sick.ru>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 Mar 2004, Gleb Smirnoff wrote:

GS>So I have proposed a different approach, and ru liked it. What will
GS>you say about it?
GS>
GS>Two new fields in struct ng_type are introduced:
GS>- u_int32_t family, a generic node type. All current nodes have this field
GS>  as 0, they have no similar properties. For example, interface node family
GS>  has value of 1.
GS>- void *family_data, a pointer to a family specific data. In case of interface
GS>  family, it'll be struct ifnet *.
GS>
GS>A macro for assigning to a specific family is written. This macro sets type
GS>and sets pointer to proper data.
GS>
GS>Within this approach we have got kind of inherited properties. The only thing
GS>node needs to join some family, is to set its family and pass pointer to data.
GS>After this, it will support all family messages. Family specific messages really
GS>never reach the node code. They are handled in ng_base.c.

It would be nice if it would be possible to classify a node to belong to
more than one family. I think, that the functionality provided by the
family stuff is more like the 'interface' stuff in Java. One example where
this can be used are specialisation of interface nodes. I'm about to
commit an ATM pseudo device node that will (among other uses) be very
helpful for automatic testing of the ATM stuff. As such it implements the
network interface messages (GET_IFINDEX, ...) plus common messages with
the real ATM device node (ng_atm; GET_CONFIG, GET_VCCS, ...). I think
there are other uses too.

I see at least two ways of implementing this:

1) by handling the assignment to a family via a generic function, that,
for example, manages an array of family/data pairs for each node. Instead
of simply checking the family type when receiving a message you'll have
to loop around (control messages handling performance shouldn't be a
bottleneck).

2) making family message handling explicite instead of implicite. In
foo_rcvmsg you would have something like:

	switch (cookie) {

	  ...

	  case NGM_IFACE_FAMILY_COOKIE:
		ng_handle_iface_family_msg(...);
		break;

	  case NGM_ATMIFACE_FAMILY_COOKIE:
		ng_handle_atmiface_family_msg(...);
		break;

	  ...
	}

The 2nd variant seems slightly more easy to implement and more flexible
than the first.

harti



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040319115814.E41950>