Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 May 2020 18:23:15 +0300
From:      Andriy Gapon <avg@FreeBSD.org>
To:        cem@freebsd.org
Cc:        src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org>
Subject:   Re: svn commit: r361363 - in head/lib/libprocstat: . zfs
Message-ID:  <323574a0-b8ae-af80-d06c-0646e0d3e4f5@FreeBSD.org>
In-Reply-To: <CAG6CVpU%2BykwgVYDJYBu0MtQJjZKxKCx%2BxOqzbAxvZBUGdde3Ag@mail.gmail.com>
References:  <202005221120.04MBKOiH003190@repo.freebsd.org> <CAG6CVpU%2BykwgVYDJYBu0MtQJjZKxKCx%2BxOqzbAxvZBUGdde3Ag@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <avg@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?323574a0-b8ae-af80-d06c-0646e0d3e4f5>