[CRIU] [PATCH RFC 0/3] Allow postpone fdinfo callbacks

[Pavel Emelyanov]

This complicates already complex fdinfo engine :(

Look what we have now:

1. Shared fds are distributed between tasks using scm_rights. To do this
   we have 3 stages -- send, open and receive and they all are strictly
   ordered to avoid lockups when tasks wait for each other for fds (before
   sending scm a task stops on a futex waiting for receiver to create the
   receiving socket)

2. Pipes (and fifos), unix sockets and TTYs generate two fds in their 
   ->open callbacls, the 2nd one can conflict with some other fd the task
   restores and (!) this "2nd one" may require sending to some other task.
   This imposes another requirement on the 3-stages engine described above.

3. Some actions can only be done only after file is created, served out
   and moved to proper position. E.g. epoll configuration and scheduling
   TCP repair off. Thus the ->post_open call :( and separate queue for
   epoll fds.

5. Slave TTYs can only be restored after respective master peers. Take into
   account the issue #2, this results in 3rd queue for slave TTYs.

6. CTTYs should be __created__ after all other TTYs are created, configured
   and served out. Thus separate stages (not only queue) for CTTYs.

Now you inject yet another different thing into this engine -- postponed
post_open callbacks. This doesn't make things better and easier to maintain
and understand.


What I talked about when asked for postponed callbacks is to try to turn
the whole engine onto list of callbacks, that may ask the caller to do
some more work. Instead, here we have all 4 stages saved, separate queus 
saved, separate run for cttys saved and only added an ability to do single
re-run of any stage.

-- Pavel