[CRIU] Issue #339

[Alexander Mihalicyn]

Hi,

It's cool that you are interested in CRIU project! You are welcome. ;)

>What is the difference between (struct unix_sk_desc) and (struct unix_sk_info) in sk-unix.c?

struct unix_sk_desc is used to store information about UNIX socket on DUMP
struct unix_sk_info is used to store ... on RESTORE stage

>Which one is required to be indexed? I am guessing unix_sk_info as it is used in find_unix_sk_by_ino().

You are right, in the issue that you have referenced above it was
described that in find_unix_sk_by_ino linear search (complexity is
O(N)) was used. That's true.
For struct unix_sk_desc as you can see
https://github.com/checkpoint-restore/criu/blob/criu-dev/criu/sockets.c#L447
https://github.com/checkpoint-restore/criu/blob/criu-dev/criu/sk-unix.c#L427
is kind of hashtable is used. So, it has amortized complexity O(1).
There we shouldn't change anything.

>I am also struggling to find the entry point for restoring the unix sockets and exit point, so that I know where to allocate and deallocate the data structure respectively.
This is entry point where we OPEN socket file descriptor on RESTORE:
https://github.com/checkpoint-restore/criu/blob/58e1bf25ce617417eedfaa06e0b7f9695bbc057a/criu/sk-unix.c#L1964
This is entry point where we GET data about socket from protobuf image:
https://github.com/checkpoint-restore/criu/blob/criu-dev/criu/sk-unix.c#L2146

>Should the data structure be generic to be used else where if needed?

IMHO, it's up to you. If you want, you could for example take the hash
table implementation that is already used for struct unix_sk_desc and
make it more generic,
then use this implementation for both struct unix_sk_desc and struct
unix_sk_info.

>Should it be implemented from scratch or could I use a library with an appropriate license?

I think it's better not to use external libraries for containers
(linked lists, trees). IMHO, we should keep the CRIU dependencies list
as small as possible.
For example, rbtree implementation is from Linux Kernel, double-linked
lists also from Linux Kernel.
I think that idea of hash table implementation you could have caught
from https://github.com/checkpoint-restore/criu/blob/criu-dev/criu/sockets.c#L447
Feel free to ask if you will meet problems!

Regards,
Alex

On Thu, Apr 9, 2020 at 4:21 PM Zeyad Yasser <zeyady98 at gmail.com> wrote:
>
> Hi Everyone,
>
> I am still new to CRIU, and would like to contribute to this project.
> I wanted to ask about the general development workflow for things like (adding features, debugging, testing, ...etc).
>
> I am also interested in this issue, it seems that it is not yet implemented.
> I wanted to inquire about a few things, I don't want to waste your time, so if you could just give me pointers on where to look and I will figure it out.
> What is the difference between (struct unix_sk_desc) and (struct unix_sk_info) in sk-unix.c? Which one is required to be indexed? I am guessing unix_sk_info as it is used in find_unix_sk_by_ino().
> I am also struggling to find the entry point for restoring the unix sockets and exit point, so that I know where to allocate and deallocate the data structure respectively.
> I think we should keep the linked list as is, in order not to break anything, and add the pointers to the new data structure.
> Should the data structure be generic to be used else where if needed? Should it be implemented from scratch or could I use a library with an appropriate license?
>
> Thank you,
> Zeyad yasser.
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu