[Devel] Re: [RFC v14-rc][PATCH 09/23] Dump open file descriptors
Oren Laadan
orenl at cs.columbia.edu
Tue Mar 24 08:37:29 PDT 2009
Serge E. Hallyn wrote:
> Quoting Dave Hansen (dave at linux.vnet.ibm.com):
>> On Fri, 2009-03-20 at 16:55 -0400, Oren Laadan wrote:
>>> Dave Hansen wrote:
>>>> On Fri, 2009-03-20 at 14:47 -0400, Oren Laadan wrote:
>>>>> + switch (inode->i_mode & S_IFMT) {
>>>>> + case S_IFREG:
>>>>> + fd_type = CR_FD_FILE;
>>>>> + break;
>>>>> + case S_IFDIR:
>>>>> + fd_type = CR_FD_DIR;
>>>>> + break;
>>>>> + default:
>>>>> + cr_hbuf_put(ctx, sizeof(*hh));
>>>>> + return -EBADF;
>>>>> + }
>>>> Why is there differentiation between files and directories? Since we
>>>> deal with them in the same way, why bother adding this code everywhere
>>>> to make them distinct?
>>> When we will handle unlinked files and unlinked directories, they will
>>> be handled differently.
>> This at *LEAST* needs a big fat comment.
>>
>> ... and unlinked files will be handled differently than normal files.
>> Can we cross that bridge when we come to it? The abstraction that I
>> drew before in my patch was this:
>>
>> CR_FD_GENERIC
>>
>> It means an fd the can be checkpointed/restored in a "generic" way,
>> namely "open()/lseek()", done. Linked directories and linked files
>> share this attribute. Unlinked files/directories do not.
>>
>> Is it more important that we classify things based on the file/directory
>> properties, or how we handle them?
>
> Did this thread die because we expect Dave's fops patch to make
> this absolete?
and I thought it just ended :)
(in fact the change is already in the current ckpt-v14 git tree).
Oren.
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list