[CRIU] [PATCH v3 00/16] AutoFS mounts migration support

[Stanislav Kinsburskiу]

14 дек. 2015 г. 8:03 PM пользователь Pavel Emelyanov <xemul at parallels.com> написал:
>
> On 12/14/2015 07:25 PM, Stanislav Kinsburskiy wrote: 
> > So, let me try summarize all we have discussed here so far: 
> > 
> > 1) Helpers: add_to_string_vargs and and construct string. You don't like 
> > them? They are more efficient, then add_options and friend, BTW. And 
> > fully generic. 

You didn't anwer on this question.

> > 2) Autofs migration data have to be represented by optional autofs 
> > structure in mount protobuf format. 
>
> Looks like yes. 
>
> > 3) Are we trying to preserve original pipe write fd on restore? If yes, 
> > then we need "used" list. 
>
> Kernel remembers this fd and shows on in options, so yes, this number 
> must be preserved. 
>
> > 4) Regardless of presence or absence of opened write end, some routing 
> > to search for file descriptor list entry is required: either to masrk 
> > write end or to clone read end. 
>
> Probably. I saw it like -- you know the pipe_id that sits in the kernel, 
> so on restore you just 'create' this pipe_info and add respective fd entry 
> to the proper task. 
>
> > 5) "Clone file descriptor list entry" helper is required to construct 
> > write end is absent. 
>
> Probably yes. 
>
> > 6) Which way should autofs restore follow: use some artificial objects, 
> > handled after all files are opened or callbacks between autofs and 
> > pipes? In case of the latter, some callback have to be put on pipe_entry 
> > structure, so it can be called in new post_open() for pipes. 
>
> From my perspective taking a task that should restore write end and 
> adding to its rst_info a file desc entry which refers to the needed 
> pipe is the easiest way to go. 
>

I don't really get it.
So, first of all, they could be many. Thus it will be a list.
There can be different ways to proceed:
1) existent (or created) write descriptor is connected somehow to autofs data (private pointer, for example, marked as used by autofs, and on post_open() callback from pipes.c it calls something like autofs_fixup(), passing there it'private data.
2) each process has a list of some objects (on rst_info), representing autofs mount, which process iterates _after_ all files are opened. In this case this object can be of any type and not connected to file descriptors at all. It have to represent autofs data and have information about write descriptor number to pass it ot kernel and close, if necessary.
3) introducing some "file desc entry" per each mount, put them in separated list, and iterate in generic fd open cycle (actually, almost the same way I made it initially).

Which one do you prefer?

> > I hope, I didn't miss anything. 
> > Please, review and comment. 
>
> -- Pavel