From owner-p4-projects@FreeBSD.ORG Tue May 8 18:54:49 2007 Return-Path: X-Original-To: p4-projects@freebsd.org Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 66D8E16A408; Tue, 8 May 2007 18:54:49 +0000 (UTC) X-Original-To: perforce@freebsd.org Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 20C4F16A406 for ; Tue, 8 May 2007 18:54:49 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outS.internet-mail-service.net (outS.internet-mail-service.net [216.240.47.242]) by mx1.freebsd.org (Postfix) with ESMTP id 0CAA813C468 for ; Tue, 8 May 2007 18:54:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Tue, 08 May 2007 11:54:48 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 51275125B40; Tue, 8 May 2007 11:54:48 -0700 (PDT) Message-ID: <4640C777.5000203@elischer.org> Date: Tue, 08 May 2007 11:54:47 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Marko Zec References: <200705072252.l47Mq4xX044896@repoman.freebsd.org> <200705080135.33036.zec@icir.org> <463FBE8E.2070604@elischer.org> <200705080755.36056.zec@icir.org> In-Reply-To: <200705080755.36056.zec@icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Perforce Change Reviews Subject: Re: PERFORCE change 119444 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2007 18:54:49 -0000 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@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: 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} 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: 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 >