Lines Matching refs:to

27 struct and are referred to as cookies.
32 are expected to embed them in their own representations.  These are referred to
87 As far as the netfs API goes, the netfs is only actually permitted to see
88 pointers to the cookies.  The cookies themselves and any objects attached to
98 object->state.  A cookie may point to a set of objects that are in different
104  (1) Preparation: states that wait for the parent objects to become ready.  The
106      be created or accessed with respect to its parent object.
111  (3) Normal running: states that allow netfs operations on objects to proceed
119 In most cases, transitioning between states is in response to signalled events.
130 The work to be done by the various states was given CPU time by the threads of
131 the slow work facility.  This was used in preference to the workqueue facility
149 to disconnecting the netfs's representation of a cache object (fscache_cookie)
160 object to transit to a state that allows access to its children:
164      Initialise the object and wait for the parent object to become active.  In
165      the cache, it is expected that it will not be possible to look an object
175      FS-Cache expects the cache backend to probe the cache to see whether this
176      object is represented there, and if it is, to see if it's valid (coherency
179      The cache should call fscache_object_lookup_negative() to indicate lookup
180      failure for whatever reason, and should call fscache_obtained_object() to
186      the first known page is uncached - as to that point there can be no data
187      to be read out of the cache for that file that isn't currently also held
193      happens if the lookup failed to find the object, or if the object's
195      FS-Cache expects the cache to create
211      are permitted to advance from FSCACHE_OBJECT_INIT state, and temporary
217      passed on to the cache.
223      going to clear out the cache entirely and reinitialise it.  It will then
224      continue to the FSCACHE_OBJECT_UPDATING state.
228      The state machine comes here to update the object in the cache from the
230      to maintain coherency.
238      error.  This would be due to a disk error or system error of some sort.
243      The object comes here if it is dying due to an error, because its parent
248      can destroy themselves.  This object waits for all its children to go away
249      before advancing to the next state.
253      The object comes to this state if it was waiting on its parent in
260      The object comes to one of these two states when dying once it is rid of
262      cookie.  In the first state, the cached data is expected to persist, and
267      The object transits to this state if the cache decides it wants to
268      withdraw the object from service, perhaps to make space, but also due to
273      The object transits to this state when the in-memory object record is
274      ready to be deleted.  The object processor shouldn't ever see an object in
281 There are a number of events that can be raised to an object state machine:
286      the cache backend to update the object, and the cache backend will ask the
297      This is used to proceed from the dying state.
309      object to be retired (deleted) or retained.
313      This is signalled when the cache backend wants to withdraw an object.
314      This means that the object will have to be detached from the netfs's
319 to sever the connection at the same time.  The state machine can just pick
320 which one it wants to honour, and that effects the other.