PERFORCE change 127942 for review

[Marko Zec]

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