I have pushed a new version of the patch set. The new version eliminates the global fsal_fd structure.
Now instead, the upper layers pass a state_t to the new calls (which have been renamed things like open2). The FSAL also is used to allocate state_t objects, so it can attach whatever it needs to the state_t. It is passed the state_type and a possible related state_t so it can decide what it needs to do. The default allocate_state method just allocates a basic state_t and fills in the bits known. There is also a free_state that allows an FSAL to take some action before freeing the memory for a state_t (such as making sure file descriptors are closed). Please have a look at this new API. Note that the start of the FSAL_VFS implementation is nowhere near complete, but should help in understanding how the interface will be used. Thanks Frank > -----Original Message----- > From: Matt W. Benjamin [mailto:m...@cohortfs.com] > Sent: Wednesday, July 29, 2015 7:02 AM > To: Daniel Gryniewicz > Cc: nfs-ganesha-devel@lists.sourceforge.net > Subject: Re: [Nfs-ganesha-devel] Multiple-fd work > > i.e., I like that it captures the idea (in multi-fd already) to allocate all at once, > and this is how I would have intuited we move to opaque user data. > > I think we can deal with whatever workaround solves locking currently > required for that object (e.g., Adam's suggestion to call up into SAL layer in > some cases), esp. since iirc an eventual step in Dan's MDCACHE work > involved lock reorganization, and a lot things will likely shake out from that? > > Matt > > ----- "Matt W. Benjamin" <m...@cohortfs.com> wrote: > > > This feels to be on the right track. > > > > Matt > > > > ----- "Daniel Gryniewicz" <d...@redhat.com> wrote: > > > > > On 07/28/2015 03:51 PM, Frank Filz wrote: > > > <snip> > > > > > > > > I was avoiding the free standing blob (at least for NFS, 9p it > > was > > > not so easy), so for NFS state_t objects, the fsal_fd is allocated > > > along with the state_t. > > > > > > > > The FSAL has to be able to indicate how much space it needs. > > > > > > > > Yes, we COULD pass the state_t (still needs to allocate some > > space > > > for FSAL somehow) instead of the fsal_fd. The question I have is > > what > > > in there is of value to the FSAL. If there really is something of > > > value, then sure, let's pass the state_t. Without something of > > value > > > though, I'm wary of exposing state_t stuff to the FSAL (for one > > thing > > > it's protected by the state_lock, which the FSAL normally doesn't > > have > > > access to). > > > > > > > > However, there is another hitch... When doing an open/create, we > > > don't have a cache entry or state_t yet (which currently means > > fsal_fd > > > is actually something that needs to be able to be copied). > > > > > > > > > > In my MDCACHE work, the state_t is completely allocated by the FSAL, > > > > > since it has to (potentially) store it as well, if there's no > > MDCACHE > > > > > > layer for that FSAL. So, it can just layer state_t, like it layers > > > > > fsal_obj_handle. The advantage of this is that it looks and behaves > > > > > just like object handles, exports, and other things that the FSAL > > > already layers. Under this paradigm, open/create would return the > > > state_t as an out param anyway. > > > > > > If this is interesting, the code to call into the FSAL to get/put > > the > > > > > > state is fairly separable, and can go in soon. > > > > > > Dan > > > > > > > > > > > ---------------------------------------------------------------------- > > -------- > > > _______________________________________________ > > > Nfs-ganesha-devel mailing list > > > Nfs-ganesha-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel > > > > -- > > Matt Benjamin > > CohortFS, LLC. > > 315 West Huron Street, Suite 140A > > Ann Arbor, Michigan 48103 > > > > http://cohortfs.com > > > > tel. 734-761-4689 > > fax. 734-769-8938 > > cel. 734-216-5309 > > > > ---------------------------------------------------------------------- > > -------- _______________________________________________ > > Nfs-ganesha-devel mailing list > > Nfs-ganesha-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel > > -- > Matt Benjamin > CohortFS, LLC. > 315 West Huron Street, Suite 140A > Ann Arbor, Michigan 48103 > > http://cohortfs.com > > tel. 734-761-4689 > fax. 734-769-8938 > cel. 734-216-5309 > > ---------------------------------------------------------------------------- -- > _______________________________________________ > Nfs-ganesha-devel mailing list > Nfs-ganesha-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel ------------------------------------------------------------------------------ _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
