I have one more idea. Currently we have got 3 interface nodes: ng_ether, ng_iface,
ng_eiface. 2 of them already support "getifindex" message, imagine I (or someone else) send
you patch tomorrow, which adds support to ng_eiface. OK, now all three support. May be
in future some new interface nodes will be developed.
Imagine the following: you have node, which is connected to some generic
interface (it doesn't know which node type exactly). This node wants to
determine interface index of attached interfac. It would send 3 "getifindex" messages with 3
different cookies. Two of messages will always fail, and one return. This is not nice.
What I suggest: create a new semi-generic cookie NGM_GENERICIFACE_COOKIE, which will be
supported by all interface nodes. Put NGM_GENERICIFACE_GETIFINDEX message under
NGM_GENERICIFACE_COOKIE case brackets. If you like this idea, please reply me. And I'll send
patches.
--
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"
On Mon, Mar 08, 2004 at 01:20:33PM +0300, Gleb Smirnoff wrote:
> On Sun, Mar 07, 2004 at 03:02:28PM -0800, Ruslan Ermilov wrote:
> R> Synopsis: [patch] new control message for ng_iface(4) - getifindex
> R>=20
> R> State-Changed-From-To: open->closed
> R> State-Changed-By: ru
> R> State-Changed-When: Sun Mar 7 15:01:03 PST 2004
> R> State-Changed-Why:=20
> R> Committed with tiny modifications, thanks!
>=20
> I have one more idea. Currently we have got 3 interface nodes: ng_ether=
, ng_iface,
> ng_eiface. 2 of them already support "getifindex" message, imagine I (or =
someone else) send
> you patch tomorrow, which adds support to ng_eiface. OK, now all three su=
pport. May be
> in future some new interface nodes will be developed.
>=20
> Imagine the following: you have node, which is connected to some generic
> interface (it doesn't know which node type exactly). This node wants to
> determine interface index of attached interfac. It would send 3 "getifind=
ex" messages with 3
> different cookies. Two of messages will always fail, and one return. This=
is not nice.
>=20
> What I suggest: create a new semi-generic cookie NGM_GENERICIFACE_COOKIE,=
which will be
> supported by all interface nodes. Put NGM_GENERICIFACE_GETIFINDEX message=
under
> NGM_GENERICIFACE_COOKIE case brackets. If you like this idea, please repl=
y me. And I'll send
> patches.
>=20
How do you think "ngctl msg ng0: getifindex" works? ;)
Cheers,
--=20
Ruslan Ermilov
FreeBSD committer
r...@FreeBSD.org
--IrhDeMKUP4DT/M7F
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFATOXDUkv4P6juNwoRAjcsAJ9iG7fvCw5klJ7niMNWHiy74YxEfwCfS/hg
Z0+iqydq1wo52dqKXojhq4A=
=7B7V
-----END PGP SIGNATURE-----
--IrhDeMKUP4DT/M7F--
So, you suggest to use ASCII message in situation described above? IMHO, ASCII messages were
invented for human interface purposes, not for node interaction.
On Tue, Mar 09, 2004 at 12:48:20AM +0300, Gleb Smirnoff wrote:
> On Mon, Mar 08, 2004 at 11:29:39PM +0200, Ruslan Ermilov wrote:
> R> > I have one more idea. Currently we have got 3 interface nodes: ng_=
ether, ng_iface,
> R> > ng_eiface. 2 of them already support "getifindex" message, imagine I=
(or someone else) send
> R> > you patch tomorrow, which adds support to ng_eiface. OK, now all thr=
ee support. May be
> R> > in future some new interface nodes will be developed.
> R> >=20
> R> > Imagine the following: you have node, which is connected to some g=
eneric
> R> > interface (it doesn't know which node type exactly). This node wants=
to
> R> > determine interface index of attached interfac. It would send 3 "get=
ifindex" messages with 3
> R> > different cookies. Two of messages will always fail, and one return.=
This is not nice.
> R> >=20
> R> > What I suggest: create a new semi-generic cookie NGM_GENERICIFACE_CO=
OKIE, which will be
> R> > supported by all interface nodes. Put NGM_GENERICIFACE_GETIFINDEX me=
ssage under
> R> > NGM_GENERICIFACE_COOKIE case brackets. If you like this idea, please=
reply me. And I'll send
> R> > patches.
> R> >=20
> R> How do you think "ngctl msg ng0: getifindex" works? ;)
>=20
> So, you suggest to use ASCII message in situation described above? IMHO, =
ASCII messages were=20
> invented for human interface purposes, not for node interaction.
>=20
OK, how about sending a NGM_NODEINFO message to the node, and
picking up XXX for (NGM_XXX_COOKIE, NGM_XXX_GET_IFNAME) based
on the returned type?
Cheers,
--=20
Ruslan Ermilov
FreeBSD committer
r...@FreeBSD.org
--Dxnq1zWXvFF0Q93v
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFATWoEUkv4P6juNwoRAhnmAJ9aN+qcR0Ccsk61ldBZrc4RqyUrQgCdGdJQ
ojZgAuxOoOGp70cTmR8+zT4=
=zrDb
-----END PGP SIGNATURE-----
--Dxnq1zWXvFF0Q93v--
GS>On Sun, Mar 07, 2004 at 03:02:28PM -0800, Ruslan Ermilov wrote:
GS>R> Synopsis: [patch] new control message for ng_iface(4) - getifindex
GS>R>
GS>R> State-Changed-From-To: open->closed
GS>R> State-Changed-By: ru
GS>R> State-Changed-When: Sun Mar 7 15:01:03 PST 2004
GS>R> State-Changed-Why:
GS>R> Committed with tiny modifications, thanks!
GS>
GS> I have one more idea. Currently we have got 3 interface nodes: ng_ether, ng_iface,
GS>ng_eiface. 2 of them already support "getifindex" message, imagine I (or someone else) send
GS>you patch tomorrow, which adds support to ng_eiface. OK, now all three support. May be
GS>in future some new interface nodes will be developed.
Don't forget about ng_atm...
harti
First, this requires some dialog-like message interchange (as well as ASCII message).
Netgraph does not provide nice API for this. I see the only way to implement:
1) send out NGM_NODEINFO message from some node method
2) catch reply in xxx_rcvmsg(), construct new message and send it
3) catch second reply in xxx_rcvmsg()
Second, this will work only with a certain number of nodes. The code of xxx_rcvmsg()
will look like:
if (msg->header.flags & NGF_RESP) {
switch (msg->header.typecookie) {
case NGM_GENERIC_COOKIE:
switch (msg->header.cmd) {
case NGM_NODEINFO:
{
struct nodeinfo *info =
(struct nodeinfo *)msg->data;
if (strcmp(info->type, NG_IFACE_NODE_TYPE, strlen(NG_IFACE_NODE_TYPE)) {
xxxxx
} else
if (strcmp(info->type, NG_ETHER_NODE_TYPE ..... {
yyyyyy
This won't be generic solution. Whenever, a new interface node is implemented (e.g. ng_atm),
our imaginary node needs a patch and ng_atm.h to be included.
My proposal brings a generic solution for any new interface node type.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE