From owner-p4-projects@FreeBSD.ORG Wed Oct 24 17:48:45 2007 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id C97AE16A41B; Wed, 24 Oct 2007 17:48:44 +0000 (UTC) Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7980516A417 for ; Wed, 24 Oct 2007 17:48:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outG.internet-mail-service.net (outG.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id 5D0BE13C4B6 for ; Wed, 24 Oct 2007 17:48:44 +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.40) with ESMTP; Wed, 24 Oct 2007 10:48:34 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 591041267EF; Wed, 24 Oct 2007 10:48:34 -0700 (PDT) Message-ID: <471F858C.20802@elischer.org> Date: Wed, 24 Oct 2007 10:49:00 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Marko Zec References: <200710230018.l9N0IO8l020652@repoman.freebsd.org> <200710232314.38149.zec@icir.org> <471E7645.1030503@elischer.org> <200710240139.00008.zec@icir.org> In-Reply-To: <200710240139.00008.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 127942 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: Wed, 24 Oct 2007 17:48:45 -0000 Marko Zec wrote: > On Wednesday 24 October 2007 00:31:33 Julian Elischer wrote: >> Marko Zec wrote: >>> On Tuesday 23 October 2007 02:49:24 Julian Elischer wrote: >>>> question: >>>> >>>> can processes in two vimages communicate if they both have access >>>> to the same named pipe/fifo in the filesystem? >>> Yes, provided that they open the fifo while they would be both >>> attached to the same vnet. Once the sockets would become open the >>> processes could reassociate to arbitrary vimages, while the sockets >>> would remain bound to their original vnets for their entire >>> lifetime duration. >> hmm that's not what I want... what I want is an ability for processes >> in two overlapping vimages to communicate easily without incuring the >> overhead of going throigh a virtual router. >> >> another possibility is a >> local: interface (address 127.1.[vnet number]) which acts like a >> local net between the virtual machines. > > Uhh I'd rather not take that path... This would require at least a) > lots of special casing all around IP stack; and b) that vimages/vnets > would need to be directly addressable by small integers. > > I'd prefer if we could work out a solution where symbolic (textual) > naming of vimages/vnets would be sufficient for all purposes... > >>> As an alternative, we could / should introduce an extended socket() >>> syscall where an additional argument would explicitly specify to >>> which vimage/vnet the new socket should belong. >> if a process in the root vimage makes fifo in >> /vimages/vimage1/usr/tmp/fifo1 >> >> and a process in vimage1 (that is chrooted at /vimages/vimage1/) >> opens the fifo at /usr/tmp/fifo1 >> >> why can't they communicate? I'm surprised at this.. > > You're right the example you gave above actually works I just tried this > out (now I'm slightly surprised :). However netstat -f unix will show > the socket pair only in one of the vimages/vnets... I don't know why I > thought there was also a prison_check() call somewhere inside or around > unp_connect() but apparently there isn't... > > So while this obviously works for you I'm not entirely sure that this is > the behavior we wish to have... As a named pipe is a note in the filesystem that both can see it would be extremely POLA if they didn't refer to the same object.. If you do make this happen, please make it configurable. > Cheers, > > Marko >