> 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
> > > FSALs.
> > >
> > Looks like the state struct is followed by per-FSAL independent data.
> >
> > A better design than this (or a union) would be container_of, so that
> > each FSAL is independent, and needs no centralized union.
>
> True.
> For me, the main thing was the idea of having it as a part of state_t.
> I knew some might object to the split alloc idea, that's why I started the
> discussion with the union.
>
> Anyway, all ideas raised so far are better than what's there, so let's see
what
> else is there to come and maybe we can agree to one then.
Yea, if we change it lets go with container_of. The union above burdens
every FSAL with the largest private fd whether it uses one or not.
container_of doesn't require split allocation.
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 {
struct state_t state;
struct my_file_descriptor my_fd;
};
Frank
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
