Caller context flags [PSARC/2007/632 FastTrack timeout 11/09/2007]

Rich.Brown at sun.com Rich.Brown at sun.com
Fri Nov 2 15:02:30 PDT 2007


I'm sponsoring this fast-track for Jim Wahlig.  This case seeks Minor binding.


Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI
This information is Copyright 2007 Sun Microsystems
1. Introduction
    1.1. Project/Component Working Name:
	 Caller context flags
    1.2. Name of Document Author/Supplier:
	 Author:  Jim Wahlig
    1.3  Date of This Document:
	02 November, 2007
4. Technical Description

     One of the uses of the caller_context structure is to pass information
     between the caller of a vnode operation (VOP) and a File Event Monitor
     (FEM).  It is used by both NFS and CIFS servers.

     Monitors often need to perform operations that would block the
     caller.  For example, an NFSv4 delegation monitor may need to
     perform an over-the-wire operation to recall a delegation.  The
     problem is that the caller may not be in a position to block and
     has no way to communicate that state to the monitor.

   Proposed Solution

     This case proposes to add a flags field (cc_flags) to the caller_context
     structure as well as values to communicate the behavior needed by the
     caller.

     The new caller context structure looks like this:
     typedef struct caller_context {
        pid_t           cc_pid;         /* Process ID of the caller */
        int             cc_sysid;       /* System ID, used for remote calls */
        u_longlong_t    cc_caller_id;   /* Identifier for (set of) caller(s) */
        uint64_t        cc_flags;  <-- NEW FLAG FIELD
     } caller_context_t;

     The first two new flags to be defined:
     #define CC_WOULDBLOCK   0x1     /* set upon return by monitor */
     #define CC_DONTBLOCK    0x2     /* set by caller */

     The caller sets CC_DONTBLOCK in cc_flags to direct the monitor not to
     perform an operation that might block.  In the case where a monitor would
     perform a blocking operation and CC_DONTBLOCK is set, the monitor
     sets CC_WOULDBLOCK in the cc_flags and returns EAGAIN to the caller.

     The first consumer of this new field would be the NFS server.  The flags
     passed would inform the monitors on delegated files whether to wait for
     the delegation to be returned or just kick off the recall and return
     an error.  The NFS server will set CC_DONTBLOCK to inform the 
     delegation monitors not to wait for a delegation to be returned when
     there is a conflict.  Instead, the monitors will return EAGAIN and set
     the CC_WOULDBLOCK flag after issuing the delegation recall.


   Exported Interfaces

                  |                |
   Interface Name | Classification | Comments
   =================================================================
                  |                |
   CC_WOULDBLOCK  | consolidation  | set when returning EAGAIN to an op
                  | private        | that would have been blocked.
                  |                |
   CC_DONTBLOCK   |                | set by caller to indicate that op's 
                  |                | should not block.

6. Resources and Schedule
    6.4. Steering Committee requested information
   	6.4.1. Consolidation C-team Name:
		ON
    6.5. ARC review type: FastTrack
    6.6. ARC Exposure: open




More information about the opensolaris-arc mailing list