> 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