From owner-p4-projects@FreeBSD.ORG Tue May 8 05:55:47 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 CBF6D16A403; Tue, 8 May 2007 05:55:46 +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 A356516A400 for ; Tue, 8 May 2007 05:55:46 +0000 (UTC) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id 33A5913C44B for ; Tue, 8 May 2007 05:55:46 +0000 (UTC) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 9CBA09B64A; Tue, 8 May 2007 07:55:44 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [192.168.200.106] (zec2.tel.fer.hr [161.53.19.79]) by xaqua.tel.fer.hr (Postfix) with ESMTP id A1A3B9B649; Tue, 8 May 2007 07:55:43 +0200 (CEST) From: Marko Zec To: Julian Elischer Date: Tue, 8 May 2007 07:55:35 +0200 User-Agent: KMail/1.9.6 References: <200705072252.l47Mq4xX044896@repoman.freebsd.org> <200705080135.33036.zec@icir.org> <463FBE8E.2070604@elischer.org> In-Reply-To: <463FBE8E.2070604@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200705080755.36056.zec@icir.org> 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 05:55:47 -0000 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? 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