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

[Artem Kuzmitskiy]

Hi Tycho,

As a whole I agreed with you, but it's was done for next reason, currently we can use only "inherit" functionality for restore and "restorer" should make a new IPC channels on user code side . 
It's means that restorer should control how many channels he has and how many new channels he should make for successful restoration.

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