Re: [RFC v14-rc2][PATCH 16/29] A new file type (CR_FD_OBJREF) for a file descriptor already setup

[Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>]

Serge E. Hallyn wrote:
> Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):
>> While file pointers are shared objects, they may share an underlying
>> object themselves. For instance, file pointers of both ends of a pipe
>> that share the same pipe inode. In this case, the shared entity to
>> handle is the inode that is shared among two file pointers (e.g read-
>> and write- ends). In this sort of "nested sharing" we need only save
>> the underlying object once (upon first encounter) on checkpoint, and
>> restore it only once during restart.
>>
>> To checkpoint a file descriptor of this sort, we first lookup the
>> inode in the hash table:
> 
> Sorry I've not followed well on irc.  What is the plan and timeline
> with respect to this and Dave's fops approach?  Is someone rewriting
> the pipes patches on top of that?  Will that replace this patch as
> well?  Who is doing it, and when will we see that patch?
> 

The fops approach is already implemented for checkpoint. I already
modified the pipe implementation accordingly.

So there are 'generic_file_checkpoint()' and 'pipe_file_checkpoint()'
both in place.

The restart is remains the same for all file types.

I think Dave is working on another change that will modify the format
of the checkpoint.

> I'm just wondering how closely to review the next 3 patches.

Please do :)

Oren.