PERFORCE change 119444 for review

Marko Zec zec at icir.org
Tue May 8 19:17:28 UTC 2007


On Tuesday 08 May 2007 20:54:47 Julian Elischer wrote:
> Marko Zec wrote:
> > On Tuesday 08 May 2007 02:04:30 Julian Elischer wrote:
> >> Marko Zec wrote:
> >>> On Tuesday 08 May 2007 01:22:59 Julian Elischer wrote:
> >>>> Marko Zec wrote:
> >>>>> http://perforce.freebsd.org/chv.cgi?CH=119444
> >>>>>
> >>>>> Change 119444 by zec at zec_tpx32 on 2007/05/07 22:51:07
> >>>>>
> >>>>> 	Add support for free-floating ng_hub and ng_bridge instances.
> >>>>>
> >>>>> 	If a hook named "anchor" is created on a ng_hub or ng_bridge
> >>>>> 	node instance, the node will not self-destruct even if it
> >>>>> 	has no hooks connected.  Reminder: normal behavior is that
> >>>>> 	hub or bridge nodes automatically destroy themselves when
> >>>>> 	the last hook is disconnected.
> >>>>
> >>>> What is this hook attached to?
> >>>> One could just as easily send them a 'become persistant'
> >>>> message.. It would be a good candidate for a generic message.
> >>>> Data is still sent to this hook. is that what is expected?
> >>>
> >>> This hook should typically disappear right after it is created,
> >>> if we use it like this:
> >>>
> >>> tpx32# ngctl mkpeer hub anchor anchor
> >>> tpx32# ngctl l
> >>> There are 3 total nodes:
> >>> Name: ngctl69865    Type: socket      ID: 0000040d   Num hooks: 0
> >>> Name: <unnamed>     Type: hub         ID: 0000040b   Num hooks: 0
> >>> Name: em0           Type: ether       ID: 00000004   Num hooks: 0
> >>>
> >>> Yes, the only purpose of this is to pin-up the node.  We cannot
> >>> send a 'become persistant' message to a node that doesn't
> >>> exist... Or do you have an alternative suggestion to achieve this
> >>> functionality?  I really need this badly for IMUNES...
> >>>
> >>> Cheers,
> >>>
> >>> Marko
> >>
> >> there is a hook when you create it.. you send it the message, then
> >> you can remove the hook.
> >
> > I'd be sold on the concept you propose if I had an idea how to use
> > it from non-interactive scripts in a reasonably simple way.  For
> > example:
> >
> > tpx32# ngctl -f -
> > mkpeer hub x x
> > list
> > # XXX what now?  Send "pin-up" message to which node?
>
> msg [429]: pin {value=1}

This won't work since the invoking script can't (at least not trivially) 
discover the ID of the new node...


> assuming we defined a message called 'pin' which had a single
> binary element called 'value'.
> (or we could define two messages. 'pin' and 'unpin' with
> no contents, like 'shutdown'.
>
>
>
> see /usr/share/example/netgraph/* for examples
>
> also :
>  http://ezine.daemonnews.org/200003/netgraph.html
>
> > There are 3 total nodes:
> > Name: <unnamed>       Type: hub         ID: 00000429   Num hooks: 1
> > Name: ngctl93546      Type: socket      ID: 00000428   Num hooks: 1
> > Name: em0             Type: ether       ID: 00000004   Num hooks: 0
> >
> > My point is that even if we don't close the controlling socket (we
> > remain in ngctl) so that we don't loose the newly created node
> > right away, how can we at this point know the address of the new
> > node without going through some woodo magic style parsing of the
> > output from currently running ngctl process, and then feeding the
> > result back to its standard input?
> >
> > Marko




More information about the p4-projects mailing list