[CRIU] Re: [PATCH 3/7] fifo: Add checkpoint restore for fifos v2

[Cyrill Gorcunov]

On Thu, Jun 28, 2012 at 09:08:03PM +0400, Pavel Emelyanov wrote:
> > +static int open_fifo_fd(struct file_desc *d)
> > +{
> > +       struct fifo_info *info = container_of(d, struct fifo_info, d);
> > +       struct reg_file_info *rfi;
> > +       struct file_desc *rd;
> > +
> > +       pr_info("\t\tCreating fifo pipe_id=%#x id=%#x\n",
> > +               info->fe.pipe_id, info->fe.id);
> > +
> > +       rd = find_file_desc_raw(FDINFO_REG, info->fe.id);
> > +       if (!rd) {
> > +               pr_perror("Can't find regfile for fifo %#x\n", info->fe.id);
> > +               return -1;
> > +       }
> > +
> > +       rfi = container_of(rd, struct reg_file_info, d);
> > +       if (rfi->open != __open_fifo_fd)
> > +               rfi->open = __open_fifo_fd;
> > +       rfi->priv = info;
> > +
> > +       return open_fe_fd(rd);
> 
> I don't understand the code above. Why do we find another file_desc while
> the one we're asked to open is passed to us as an argument?
> 
> > +}
> > +

Because we need to find appropriate reg_file_info descriptor for this
fifo file descriptor. Look, we dump fifo in two places -- as regfile
for path and flags sake and as fifo_entry.

So when we restore the fifo the restorer engine first call open_fifo_fd
with file_desc which maps fifo_entry then we use reg files engine to
create fifo file for us

dump
	dump_one_fifo
		dump_one_reg_file
		write fifo_entry

restore
	open_fifo_fd
		manually call for open_fe_fd routine
		but open_fe_fd expects reg_file_info,
		so we pass 1:1 mapped descriptor.
> 
> > @@ -161,6 +164,22 @@ struct pipe_data_entry {
> >         u8      data[0];
> >  } __packed;
> > 
> > +struct fifo_entry {
> > +       u32     id;
> > +
> > +       /*
> > +        * FIXME
> 
> Why FIXME? ID is an ID of a file, while pipe_id is an ID of fifo inode.
> It cannot be fixed at all!

Well, at first I thought to unify pipe data engine to use some abstract
number-through scheme, but indeed it looks like overengineering.

	Cyrill