[CRIU] Re: [PATCH 5/8] pipes: Add c/r for fifo files

[Pavel Emelyanov]

On 06/22/2012 05:25 PM, Cyrill Gorcunov wrote:
> On Fri, Jun 22, 2012 at 05:10:06PM +0400, Pavel Emelyanov wrote:
>> On 06/22/2012 04:24 PM, Cyrill Gorcunov wrote:
>>>
>>> Basically pipes are superset over fifos, so we integrate
>>> fifo c/r into pipes.c file.
>>>
>>> There os acatually a trick used to open fifo files --
>>> since fifo may block on opening we create a fake fifo
>>> to be able to proceed without sleeping.
>>>
>>> Signed-off-by: Cyrill Gorcunov <gorcunov at openvz.org>
>>> ---
>>>  cr-dump.c       |    8 ++-
>>>  cr-show.c       |   15 +++-
>>>  include/image.h |   10 +++
>>>  include/pipes.h |   14 ++-
>>>  pipes.c         |  220 +++++++++++++++++++++++++++++++++++++++++++++++-------
>>>  5 files changed, 229 insertions(+), 38 deletions(-)
>>>
>>
>> After more thinking. Why fifos has anything to do with pipes.c except for the
>> "pipe data". The whole (other than pipedata) code in pipe.c was written to handle
>> the double-ended pipe nature. With fifos you can _just_ dump it as a regular file
>> (plus the trick with fake fifo) and restore the pipe data at the end. No?
> 
> Nope ;) I can't dump it the same way as we do for regular files, the only common
> point between files and fifos are that they both do have a path on filesystem.

How open files are dumped/restored:

1. get st_ino for id
2. write fd, type == REG and id into fdinfo.img
3. get file path with not-so-simple procedure
4. write path, pos and flags into reg_files.img

1. read fd, type and id from fdinfo.img
2. read the id's entry from reg_files.img
3. calculate the path
4. open (literally -- call open()) the obtained path with obtained flags
5. tune position with lseek

How pipes are dumped/restored

1. get st_ino for id
2. write fd, type = PIPE and id into fdinfo.img
3. write pipe id into pipes.img
4. write pipe data into pipe-data.img

1. read fd, type and id from fdinfo.img
2. perform quite complex resorting of this one to check who
   will call pipe() and who will wait for the pipe on a unix socket
3. call pipe() or call socket+recv()
4. push pipe data into a suitable end

Now how fifos should be dumped/restored in theory

1. get st_ino for id
2. write fd, type == FIFO and id into fdinfo.img
3. get fifo path like how it's done for files
4. write path, pos and flags into some.img
5. write fifo data into fifo-data.img/pipe-data.img

1. read fd, type and id from fdinfo.img
2. read the id's entry from some.img
3. calculate the path
4. open (literally -- call open() and this is the core thing -- you DO open
   fifos with open) the obtained path with obtained flags
5. push fifo data into a suitable end

> [ Also fifos do share a number of code with pipes in kernel (same mechanism for
>   buffers and such) which points to -- the fifo is rather a pipe than a file and
>   I think we should reflect this in our code base too, no? ]

O yeah, but they also have tons of code shared with regular files -- all the
lookup/create/unlink/etc. paths and they are MUCH bigger.

> In summay -- I think grouping fifo code into pipe is a good idea, file-regs should
> remain for regular files handling only, the lack of a general path-remap mechanism
> (which would be suitable to use with non-reg files as well) doesn't justify
> spreading fifo code between regular files and pipes. I think ;)
> 
> After all, Pavel, I might be missing something, because I can imagine how would
> we use reg-files code for fifo dumping.

I think the best we can do is put all this stuff into fifo.c file which will call
functions from files-reg.c and pipe.c for handling paths and pipe data respectively.

> 	Cyrill
> .
>