On 22/05/2020 18:15, Conrad Meyer wrote: > Hi Andriy, > > Would it make sense to also export sizes of those members? Currently > the code assumes the members may be relocated in the struct, but never > changed in size. If they can be moved around, maybe they might be > enlarged or shrunk at some time too? Maybe not; I am not very > familiar with ZFS.
I think that's less likely to happen. I mean, moving around may be as simple as adding a new field in the middle of the struct and people typically don't give much thought to such changes. Changing a member's type is more likely to prompt a check of possible uses. But less likely does not equal will never happen, of course. So, I think that this is a good suggestion. > On Fri, May 22, 2020 at 4:20 AM Andriy Gapon <a...@freebsd.org> wrote: >> >> Author: avg >> Date: Fri May 22 11:20:23 2020 >> New Revision: 361363 >> URL: https://svnweb.freebsd.org/changeset/base/361363 >> >> Log: >> libprocstat: fix ZFS support >> >> First of all, znode_phys_t hasn't been used for storing file attributes >> for a long time now. Modern ZFS versions use a System Attribute table >> with a flexible layout. But more importantly all the required >> information is available in znode_t itself. >> >> It's not easy to include zfs_znode.h in userland without breaking code >> because the most interesting parts of the header are kernel-only. And >> hardcoding field offsets is too fragile. So, I created a new >> compilation unit that includes zfs_znode.h using some mild kludges to >> get it and its dependencies to compile in userland. The compilation >> unit exports interesting field offsets and does not have any other code. >> >> PR: 194117 >> Reviewed by: markj >> MFC after: 2 weeks >> Sponsored by: Panzura -- Andriy Gapon _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
