Date: Wed, 24 Oct 2007 01:38:59 +0200 From: Marko Zec <zec@icir.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 127942 for review Message-ID: <200710240139.00008.zec@icir.org> In-Reply-To: <471E7645.1030503@elischer.org> References: <200710230018.l9N0IO8l020652@repoman.freebsd.org> <200710232314.38149.zec@icir.org> <471E7645.1030503@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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... Cheers, Marko
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200710240139.00008.zec>