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

[Artem Kuzmitskiy]

> If I understand correctly, you're describing a case where there is
> some connection state that needs to be negotiated at the application
> layer before it is really "restored". That is, there is more than just
> reconnecting the sockets required.

Primarily, I spoke about next case:
Parent process calls fork() and starts communicates with child via sockets which were created using socketpairs().
We can't reconnect this type of socket and should use "inherit". Inodes are required for "inherit"  mode. 
I think more clearly if parent process will collect inodes and explicitly pass their to command line option.
But for other types of sockets it's really not required(in case if we can reconnect their).
Inodes values is optional attribute of --ext-unix-sk and we can implement general case.


> Best regards,
> Artem Kuzmitskiy
> LG Russia R&D Lab, St.-Petersburg
> ________________________________________
> От: Tycho Andersen [tycho.andersen at canonical.com]
> Отправлено: 10 ноября 2015 г. 3:00
> Кому: Artem Kuzmitskiy/Russia R&D Lab Web Team Web 3 Part(artem.kuzmitskiy at lge.com); criu at openvz.org
> Тема: alternate implementation of --ext-unix-sk
>
> 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.
>
> Thanks,
>
> Tycho