[CRIU] alternate implementation of --ext-unix-sk

[Tycho Andersen]

On Wed, Nov 11, 2015 at 03:41:50PM +0300, Pavel Emelyanov wrote:
> On 11/11/2015 12:14 PM, Pavel Emelyanov wrote:
> > On 11/10/2015 03:00 AM, Tycho Andersen wrote:
> >> Hi all,
> >>
> >> in 79fd764ae6c4eabcc12da0159e4ad96b02431df0 and
> >> http://criu.org/External_UNIX_socket#What_to_do_with_socketpair.28.29-s.3F
> >>
> >> an implementation of --ext-unix-sk is described that you pass the
> >> inode of the external socket. One way to find this inode is to look
> >> for a specific path in /proc/net/unix inside the container's netns.
> >>
> >> Is there any reason we can't just pass --ext-unix-sk=/foo/bar and have
> >> every socket connected to this be dumpable and restorable (by being
> >> reconnected as described on the wiki)? This would be less work (and
> >> more intiutive, I think) for most than passing the inode number, but I
> >> might be missing something.
> > 
> > The path is quite bad socket identifier because different sockets may have
> > the same name.
> > 
> > Another argument for the inode number was -- at restore time caller will
> > have to create a socket pair and pass one end of it into the criu via the
> > --inherit-fd option. In other words user of external unix sockets feature
> > deals with sockets via file descriptor on restore and thus, likely, on
> > dump too. But getting inode number out of descriptor is slightly easier 
> > than getting the socket path via it -- stat() returns 4 bytes number, while
> > getsockname() returns a string, that can start with \0 (anonymous socket
> > names), then you have to call strlen(), allocate memory for option and and
> > copy name there.
> 
> Oh, and the main reason I've just remembered :) If you have a socketpair()-ed
> end you want to "inherit" there's no name you can refer to :(

I see, ok, thanks. I'll see about doing a patch for the inode thing
then, I'm not entirely sure if we're going to need it or not.

Tycho