On Do, 2017-02-23 at 08:35 -0800, Frank Filz wrote:
> >
> However, don't add state_t to the private fd since the global fd does
> not
> need a state and that would needlessly enlarge every FSAL object
> handle.
>
> Instead make a containing structure:
>
> struct myfsal_state_and_fd {
>
> On Do, 2017-02-23 at 04:40 -0500, William Allen Simpson wrote:
> > On 2/23/17 3:43 AM, Swen Schillig wrote:
> > >
> > > while removing some legacy GPFS code I stumbled over this
> > >
> > > my_fd = (struct gpfs_fd *)(state + 1);
> > >
> > > which is probably just copied from an early version
On Do, 2017-02-23 at 04:40 -0500, William Allen Simpson wrote:
> On 2/23/17 3:43 AM, Swen Schillig wrote:
> >
> > while removing some legacy GPFS code I stumbled over this
> >
> > my_fd = (struct gpfs_fd *)(state + 1);
> >
> > which is probably just copied from an early version to all our
>
On 2/23/17 3:43 AM, Swen Schillig wrote:
> while removing some legacy GPFS code I stumbled over this
>
> my_fd = (struct gpfs_fd *)(state + 1);
>
> which is probably just copied from an early version to all our FSALs.
>
Looks like the state struct is followed by per-FSAL independent data.
A
On Do, 2017-02-23 at 14:28 +0530, Malahal Naineni wrote:
> That won't work for out of tree fsals, right? Either decouple them
> with a pointer or have a suitable macro to convert. To avoid split
> allocs, a macro would be better.
>
> Regards, Malahal.
> PS: #define GPFS_STATE2FD(state) ((struct
