Changing refcount(9) to use a refcount_t

[Ed Schouten]

Hi Pawel,

* Pawel Jakub Dawidek <pjd at FreeBSD.org>, 20111223 12:28:
> On Thu, Dec 22, 2011 at 10:47:28PM +0100, Ed Schouten wrote:
> > The reason why I'm emailing this to fs@, is because this change breaks
> > one of the existing file system drivers, namely ZFS. Solaris also
> > implements a refcount_t, but unlike FreeBSD's, it has a more complex API
> > and is 64-bits in size. Still, I suspect it's hard to overflow a 32-bit
> > reference counter, right? Even if it is, we can fix this in the long run
> > by making refcount_t a truly opaque object of type u_long.
> > 
> > Can any of you ZFS user please try the following patch? Do any of you
> > object if I commit it to SVN and merge it in a couple of months from
> > now?
> 
> Ed, what is the purpose of the patch exactly? Is there no way to keep
> ZFS as it is? Will it stop compile? Even with -std=c99?
> 
> You changing here vendor code and we still don't want to do that if
> avoidable, as we want to share code with IllumOS. Unless I see strong
> reasons why this is unavoidable, I do object. If that was our own code,
> reducing it would be definiately welcome, but because we share the code,
> we will just grow the diff against other ZFS versions out there.

The problem is that the patch adds refcount_t to <sys/refcount.h>, while
the ZFS code has its own refcount_t which has a similar purpose. This
causes a compilation error because of redefinitions.

I could simply remove the #include_next <sys/refcount.h>, but the
problem then becomes that if we start using refcount_t in our own
sources (e.g. in struct session in <sys/proc.h>), we end up having
structure size mismatches between ZFS and the rest of the kernel.

I could also pick a different name, like refcnt_t, but that would make
little sense. We would then have functions starting with refcount_*,
operating on a refcnt_t.

Of course, I share your opinion that we should prevent unneeded changes
to vendor code, but we shouldn't deviate from our own naming scheme in
the process.

It must be mentioned that this approach may lead to a decrease in code
eventually. The Solaris refcount API doesn't look too bad. Maybe we
could eventually incorporate some of its facets into our own API,
potentially making the CDDL refcount.h superfluous.

-- 
 Ed Schouten <ed at 80386.nl>
 WWW: http://80386.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20111223/ba5d2757/attachment.pgp