Date: Fri, 22 May 2020 18:26:24 +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: <89c8638a-ed49-3fbd-ee36-175fd7ede15c@FreeBSD.org> In-Reply-To: <323574a0-b8ae-af80-d06c-0646e0d3e4f5@FreeBSD.org> References: <202005221120.04MBKOiH003190@repo.freebsd.org> <CAG6CVpU%2BykwgVYDJYBu0MtQJjZKxKCx%2BxOqzbAxvZBUGdde3Ag@mail.gmail.com> <323574a0-b8ae-af80-d06c-0646e0d3e4f5@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22/05/2020 18:23, Andriy Gapon wrote: > 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. > OTOH, z_id and z_size probably won't grow larger than 64-bit soon. Size of mode_t has been pretty stable over the years as well. So, this is not a priority for now. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?89c8638a-ed49-3fbd-ee36-175fd7ede15c>