xrootd
XrdCmsXmi.hh
Go to the documentation of this file.
1 #ifndef __XRDCMSXMI_H__
2 #define __XRDCMSXMI_H__
3 /******************************************************************************/
4 /* */
5 /* X r d C m s X m i . h h */
6 /* */
7 /* (c) 2007 by the Board of Trustees of the Leland Stanford, Jr., University */
8 /* All Rights Reserved */
9 /* Produced by Andrew Hanushevsky for Stanford University under contract */
10 /* DE-AC02-76-SFO0515 with the Department of Energy */
11 /* */
12 /* This file is part of the XRootD software suite. */
13 /* */
14 /* XRootD is free software: you can redistribute it and/or modify it under */
15 /* the terms of the GNU Lesser General Public License as published by the */
16 /* Free Software Foundation, either version 3 of the License, or (at your */
17 /* option) any later version. */
18 /* */
19 /* XRootD is distributed in the hope that it will be useful, but WITHOUT */
20 /* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or */
21 /* FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public */
22 /* License for more details. */
23 /* */
24 /* You should have received a copy of the GNU Lesser General Public License */
25 /* along with XRootD in a file called COPYING.LESSER (LGPL license) and file */
26 /* COPYING (GPL license). If not, see <http://www.gnu.org/licenses/>. */
27 /* */
28 /* The copyright holder's institutional names and contributor's names may not */
29 /* be used to endorse or promote products derived from this software without */
30 /* specific prior written permission of the institution or contributor. */
31 /******************************************************************************/
32 
33 #include <sys/types.h>
34 
35 #include "XrdCms/XrdCmsReq.hh"
36 
37 /*
38  The XrdCmsXmi class defines the interface the cmsd uses to an external
39  manager. When the cms.xmilib directive is specified, the cmsd loads the
40  plugin using XrdCmsgetXmi() to instantiate the plugin objects, as explained
41  after the definition of the abstract class. The cmsd then uses the Xmi
42  defined methods to process certain requests instead of it's own default
43  methods. As the Xmi interface runs synchronously with respect to being called,
44  it should dispatch any long work to another thread to allow the next request
45  to be processed by the plugin. You should use the thread scheduler passed
46  via the XrdCmsXmiEnv structure (see below).
47 
48  Each method (other that Prep(), see below) is passed an XrdCmsReq object.
49  This object must be used to send a reply to the client (only one reply is
50  allowed). A reply is *mandatory* if the function returns TRUE; even if that
51  reply is merely an indication that everything succeeded. A reply must *not*
52  be sent if the function returns FALSE; as a reply will be sent by the driver.
53  Refer to XrdCmsReq.hh on the description of how replies are effected.
54 
55  The mv, rm, and rmdir methods may be called in an advisory way. This occurs
56  during cross-cache synchronization when more than one redirector is deployed.
57  Use the XrdCmsReq::Advisory() method in determine if this is an action call
58  or an advisory call.
59 
60  The Prep() method is a background function and the client never expects a
61  reply. Therefore, no request object is passed since no reply is possible.
62  Instead, the first parameter is a request ID that is used to tag the
63  request. This ID may be passed later with XMI_CANCEL set to cancel and
64  path passed as a null string. All preparation for files tagged with request
65  ID should be stopped, if possible.
66 
67  The Xmi methods may be called in one of two modes, DIRECT or INDIRECT.
68  The modes are indicated by XeqMode(). In DIRECT mode the Xmi methods are
69  called synchronously. In INDIRECT mode, the Xmi methods are given thread as
70  well as client isolation by the cmsd using an asynchronous encapsulated
71  callback mechanism. Normally, INDIRECT mode should be used. The
72  implementation is not particularly relevant as the protocol details are
73  handled by the Xmi driver and the request object.
74 
75  Each method must return either true (1) or false (0). However, the action
76  taken based on the return value depends on the calling mode.
77 
78  TRUE (1) -> The function was processed and a reply was sent.
79  Action: INDIRECT: Normal processing continues, the request was done.
80  DIRECT: Same as above.
81  FALSE (0) -> The function was *not* processed and *no* reply was sent.
82  Action: INDIRECT: An error reply is sent and processing continues.
83  DIRECT: Processing continues as if the Xmi was not present.
84 
85  See the description of XeqMode() on how to indicate which methods are to
86  be called and which mode each method requires.
87 */
88 
89 /******************************************************************************/
90 /* X r d C m s X m i E n v */
91 /******************************************************************************/
92 
93 /* The XrdCmsXmiEnv structure is passed to XrdCmsgetXmi() and contains
94  information that may be relevant to the Xmi object. The information is
95  static in that it persists during the execution of the program.
96 */
97 
98 class XrdSysError;
99 class XrdInet;
100 class XrdScheduler;
101 class XrdOucName2Name;
102 class XrdOucTrace;
103 
105 {
106 const char *Role; // Manager | Peer | Proxy | Supervisor | Server
107 const char *ConfigFN; // -> Config file name
108 const char *Parms; // -> Optional parms from xmilib directive
109 XrdSysError *eDest; // -> Error message handler
110 XrdInet *iNet; // -> Network object
111 XrdScheduler *Sched; // -> Thread scheduler
112 XrdOucTrace *Trace; // -> Trace handler
113 XrdOucName2Name *Name2Name; // -> lfn to xxx mapper (may be null)
114 };
115 
116 /******************************************************************************/
117 /* X r d C m s X m i */
118 /******************************************************************************/
119 
120 class XrdCmsPrepArgs;
121 
122 // Flags passed to Prep(): XMI_RW, XMI_CANCEL
123 // Flags passed to Select(): XMI_RW, XMI_NEW, XMI_TRUNC, XMI_LOCATE
124 //
125 #define XMI_RW 0x0001
126 #define XMI_NEW 0x0002
127 #define XMI_TRUNC 0x0004
128 #define XMI_CANCEL 0x0008
129 #define XMI_LOCATE 0x0010
130 
131 // Flags to be passed back by XeqMode()
132 //
133 #define XMI_CHMOD 0x00000001
134 #define XMI_LOAD 0x00000002
135 #define XMI_MKDIR 0x00000004
136 #define XMI_MKPATH 0x00000008
137 #define XMI_PREP 0x00000010
138 #define XMI_RENAME 0x00000020
139 #define XMI_REMDIR 0x00000040
140 #define XMI_REMOVE 0x00000080
141 #define XMI_SELECT 0x00000100
142 #define XMI_SPACE 0x00000200
143 #define XMI_STAT 0x00000400
144 #define XMI_ALL 0x000007ff
145 
147 {
148 public:
149 
150 // Called when trying to change the mode of a file; opaque may be a nil ptr.
151 //
152 virtual int Chmod ( XrdCmsReq *Request,
153  mode_t mode,
154  const char *path,
155  const char *opaque) = 0;
156 
157 // Called when trying to determine the load on this host (not yet implemented)
158 //
159 virtual int Load ( XrdCmsReq *Request) {return 0;} // Server only
160 
161 // Called to make a directory; opaque may be a nil ptr.
162 //
163 virtual int Mkdir ( XrdCmsReq *Request,
164  mode_t mode,
165  const char *path,
166  const char *opaque) = 0;
167 
168 // Called to make a directory path; opaque may be a nil ptr.
169 //
170 virtual int Mkpath( XrdCmsReq *Request,
171  mode_t mode,
172  const char *path,
173  const char *opaque) = 0;
174 
175 // Called to prepare future access to a file; opaque may be a nil ptr.
176 //
177 virtual int Prep (const char *ReqID,
178  int Opts,
179  const char *Path,
180  const char *Opaque) = 0;
181 
182 // Called to rename a file or directory; oldopaque/newopaque may be a nil ptrs.
183 //
184 virtual int Rename( XrdCmsReq *Request,
185  const char *oldpath,
186  const char *oldopaque,
187  const char *newpath,
188  const char *newopaque) = 0;
189 
190 // Called to remove a directory; opaque may be a nil ptr.
191 //
192 virtual int Remdir( XrdCmsReq *Request,
193  const char *path,
194  const char *opaque) = 0;
195 
196 // Called to remove a file; opaque may be a nil ptr.
197 //
198 virtual int Remove( XrdCmsReq *Request,
199  const char *path,
200  const char *opaque) = 0;
201 
202 // Called when a client attempts to locate or open a file. The opts indicate
203 // how the file will used and whether it is to be created. The opaque may be
204 // a nil ptr.
205 //
206 virtual int Select( XrdCmsReq *Request, // See description above
207  int opts,
208  const char *path,
209  const char *opaque) = 0;
210 
211 // Called to determine how much space exists in this server (not implemented)
212 //
213 virtual int Space ( XrdCmsReq *Request) {return 0;} // Server Only
214 
215 // Called to get information about a file; opaque may be a nil ptr.
216 //
217 virtual int Stat ( XrdCmsReq *Request,
218  const char *path,
219  const char *opaque) = 0;
220 
221 // Called after the plugin is loaded to determine which and how the above
222 // methods are to be called.
223 //
224 virtual void XeqMode(unsigned int &isNormal,
225  unsigned int &isDirect)
226  {isNormal = XMI_LOAD | XMI_SPACE; isDirect = 0;}
227 
229 virtual ~XrdCmsXmi() {}
230 };
231 
232 /*
233  The XrdCmsXmi object is intended to be supplied as a plugin from a shared
234  library. This library is identified by the "cms.xmilib" directive. When
235  the library is loaded the following extern "C" function is called to obtain
236  an instance of the XrdCmsXmi object that will be used for request processing.
237  The function is passed the command line arguments (xrd options stripped) and
238  a pointer to the XrdCmsXmiEnv structure. If the function returns a null
239  pointer, the cmsd exits with an error.
240 
241  After the object is obtained, XeqMode() is called to determine how each
242  method is to operate by default. A value must be set in each provided mask
243  for each method, as applicable. Two mask are supplied:
244 
245  isNormal When the XMI_func bit is set in this mask, the corresponding
246  method is executed in the normal way the cmsd would
247  have done it had the plugin not existed. Otherwise,
248  you will have to indicate this at run-time for each call
249  which can only be done in direct calling mode.
250 
251  isDirect When the XMI_func bit is set in this mask, the corresponding
252  method is called directly without thread isolation. Use
253  this mode if the processing is immediate (e.g., you will
254  be imediately redirecting the client). By default, the
255  client is told to wait for a defered response and the
256  request is queued for a thread running the Xmi plugin.
257  Three threads are used to drive the Xmi:
258  1) A thread to feed Prep()
259  2) A thread to feed Select()
260  3) A thread to feed everything else.
261  Warning! The three thread model obviously affects how
262  objects can be shared!
263 */
264 
265 extern "C"
266 {
267 XrdCmsXmi *XrdCmsgetXmi(int argc, char **argv, XrdCmsXmiEnv *XmiEnv);
268 }
269 #endif