[Devel] Re: [RFC v14-rc][PATCH 09/23] Dump open file descriptors
Serge E. Hallyn
serue at us.ibm.com
Tue Mar 24 08:24:42 PDT 2009
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?
-serge
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list