Re: [RFC v14-rc][PATCH 09/23] Dump open file descriptors

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

-- Dave

_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers

[Index of Archives]     [Cgroups]     [Netdev]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux