From owner-p4-projects@FreeBSD.ORG Tue May 8 19:17:35 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 03DB716A473; Tue, 8 May 2007 19:17:35 +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 D499B16A409 for ; Tue, 8 May 2007 19:17:34 +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 6412213C43E for ; Tue, 8 May 2007 19:17:34 +0000 (UTC) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id B099F9B659; Tue, 8 May 2007 21:17:33 +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 B0E439B654; Tue, 8 May 2007 21:17:32 +0200 (CEST) From: Marko Zec To: Julian Elischer Date: Tue, 8 May 2007 21:17:25 +0200 User-Agent: KMail/1.9.6 References: <200705072252.l47Mq4xX044896@repoman.freebsd.org> <200705080755.36056.zec@icir.org> <4640C835.4050502@elischer.org> In-Reply-To: <4640C835.4050502@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200705082117.25633.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 19:17:35 -0000 On Tuesday 08 May 2007 20:57:57 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@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 > > msg .:x pin {value=1} Bingo - yup this should / must work! Thanks!!! Marko > > 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