Lines Matching refs:hook

14 	has to be provided. As for any other module the \c std_ops() hook is invoked
87 	A FS module has to (or can) provide quite a lot of hook functions. There are
93 	  hook functions: <tt>open*()</tt>, <tt>close*()</tt>, and
94 	  <tt>free*_cookie()</tt>. The <tt>open*()</tt> hook is passed all that is
102 	  hook is invoked to signal that the cookie is to be closed. At this point
105 	  the cookie stops being in use the <tt>free*_cookie()</tt> hook is called;
111 	  iteration through the contained objects. The <tt>read_*()</tt> hook reads
113 	  <tt>rewind_*()</tt> hook resets the iteration state to the first entry.
117 	  <tt>read*_stat()</tt> hook and must be written into a <tt>struct stat</tt>
132 	hook to let it create the respective node handle (unless the FS requests the
134 	only hook that specifies a node by ID; all other node-related hooks are
138 	hook or, if the node was marked removed,
144 	hook. It is supposed to call \c publish_vnode() for the root node of the
147 	hook. Given a \c fs_vnode object of a directory and an entry name, it is
170 	  The VFS uses this hook to resolve path names. It is probably one of the
190 	  files, the hook has to be present anyway; it should return an error in
219 	  node. If the hook is absent the user is considered to have all
225 	While there is the \link fs_vnode_ops::access access() \endlink hook
228 	It could be cheaper for the FS to do that in the respective hook (at least
230 	conditions between the check and the start of the operation for the hook.
236 	  of the checks can already be done in the respective <tt>open*()</tt> hook.
241 	- The core of the fs_vnode_ops::access() hook can be moved into a private
307 	  the fs_vnode_ops::io() hook.
312 	  the VFS will call the fs_vnode_ops::lookup() hook for each element of the