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

[Pavel Emelyanov]

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 :(

-- Pavel