Re: fcntl & cmsg

[David Holland <dholland-tech%netbsd.org@localhost>]

On Fri, Sep 19, 2014 at 03:38:19PM -0400, James K. Lowden wrote:
 > unix(4) contains an "interesting" sentence:
 > 
 >           "The received descriptor is a duplicate of the sender's
 > descriptor, as if it were created with a call to dup(2).  Per-process
 > descriptor flags, set with fcntl(2), are not passed to a receiver."
 > 
 > because fcntl(2) doesn't define "per-process" descriptor flags.  Does
 > the sentence mean "any flag set with fcntl", or are some flags
 > per-process?  If the latter, is the reader supposed to be able to
 > determine which flags are per-process from the context?  

I don't know what the documentation is supposed to mean, but the way
it's supposed to behave is:

   - fd passing is like calling dup2() except that (once received) the
     new fd appears in another process;

   - this means that the close-on-exec flag, which is per file handle,
     is not shared;

   - everything else is an attribute of the open file object (or in
     some cases the vnode, e.g. with F_SETLK or flock()) and should be
     shared between the two references.

 > McKusick distinguishes between a "file entry" describing an open file,

I think by "file entry" this means "open file object" or in NetBSD,
"struct file". The per-process open file table is an array of
references to these.

They aren't the same as vnodes; vnodes are one layer deeper.

Some people use the words "file descriptor" to refer to the open file
object as well as to the integer that consitutes a user-level
reference to it. This can occasionally be confusing...

 > (Can anyone explain why close-on-exec isn't just another option for
 > F_SETFL?  I see that dup(2) preserves the F_SETFL flags but not
 > close-on-exec. Interesting choice....)

Because it's per-handle instead of per-object. That in turn is to make
close-on-exec and I/O redirection interact productively.

-- 
David A. Holland
dholland%netbsd.org@localhost