[CRIU] Re: [PATCH 3/7] fifo: Add checkpoint restore for fifos v2
Pavel Emelyanov
xemul at parallels.com
Thu Jun 28 13:08:03 EDT 2012
> +static int __open_fifo_fd(struct reg_file_info *rfi)
> +{
> + struct fifo_info *info = rfi->priv;
> + int new_fifo, fake_fifo = -1;
> +
> + /*
> + * The fifos (except read-write fifos) do wait until
> + * another pipe-end get connected, so to be able to
> + * proceed the restoration procedure we open a fake
> + * fifo here.
> + */
> + fake_fifo = open(rfi->path, O_RDWR);
> + if (fake_fifo < 0) {
> + pr_perror("Can't open fake fifo %#x [%s]", info->fe.id, rfi->path);
> + return -1;
> + }
> +
> + new_fifo = open(rfi->path, rfi->rfe.flags);
> + if (new_fifo < 0) {
> + pr_perror("Can't open fifo %#x [%s]", info->fe.id, rfi->path);
> + goto out;
> + }
> +
> + if (restore_pipe_data(CR_FD_FIFO_DATA, fake_fifo, info->fe.id,
> + info->bytes, info->off)) {
> + close(new_fifo);
> + new_fifo = -1;
> + }
> +
> +out:
> + close(fake_fifo);
> + return new_fifo;
> +}
> +
> +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?
> +}
> +
> @@ -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!
> + * Since we keep fifo data in the same
> + * file format as the pipe data, at moment
> + * all entries are addressed via pipe_id,
> + * but this should be reworked and both
> + * pipes data and fifo data should be
> + * addressed via number through strategy
> + * and kept in one image on disk.
> + */
> + u32 pipe_id;
> +} __packed;
> +
> /*
> * splice() connect cache pages to pipe buffer, so
> * some part of pages may be loosed if data are not
> --
> 1.7.7.6
>
> .
>
More information about the CRIU
mailing list