Nodes having common properties. Was: kern/63864: [patch] new
Gleb Smirnoff
on some OO like model: if we invent some generic properties for
all interface nodes, they must be inherited, rather than supported
by the node itself.
So I have proposed a different approach, and ru liked it. What will
you say about it?
Two new fields in struct ng_type are introduced:
- u_int32_t family, a generic node type. All current nodes have this field
as 0, they have no similar properties. For example, interface node family
has value of 1.
- void *family_data, a pointer to a family specific data. In case of interface
family, it'll be struct ifnet *.
A macro for assigning to a specific family is written. This macro sets type
and sets pointer to proper data.
Within this approach we have got kind of inherited properties. The only thing
node needs to join some family, is to set its family and pass pointer to data.
After this, it will support all family messages. Family specific messages really
never reach the node code. They are handled in ng_base.c.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
_______________________________________________
freeb...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
Harti Brandt
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
Gleb Smirnoff
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
Harti Brandt
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
Gleb Smirnoff
H> From the point of code duplication and extendibility both approaches are
H> equivalent. In the second case you have the same three lines in the rcvmsg
H> function of every node that supports a given familiy (this is reduceable
H> to 1 line by defining appropriate macros), in the first one you have the
H> same line in every constructor. Perhaps I made not clear that the message
H> handling function for the familiy is not in the node's code nor in the
H> netgraph base code, but in a family file (in both cases) and module.
I understand, now. If ng_process_family_xxx_msg() is out of node, than
you are right - approeaches are equivalent.
H> But I have no strong opinion: either way does it as long as it allows
H> multiple interfaces to a given node.
OK, let's wait for reply from someone in Cc:
:)
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE