Date: Fri, 23 Dec 2011 12:59:31 +0100 From: Ed Schouten <ed@80386.nl> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-fs@FreeBSD.org Subject: Re: Changing refcount(9) to use a refcount_t Message-ID: <20111223115931.GY1771@hoeg.nl> In-Reply-To: <20111223112846.GA1679@garage.freebsd.pl> References: <20111222214728.GV1771@hoeg.nl> <20111223112846.GA1679@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
--KGRu7WxDW0E86NnQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Pawel, * Pawel Jakub Dawidek <pjd@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. > >=20 > > 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? >=20 > 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=3Dc99? >=20 > 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. --=20 Ed Schouten <ed@80386.nl> WWW: http://80386.nl/ --KGRu7WxDW0E86NnQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJO9G0jAAoJEG5e2P40kaK7fJwP/iWLxdnt5T3wlLAnWuXJp24a MUeavJEGrxbMCiheYFC7BgqVJ11fY+l2rhcM1BSDFBJxIHQbuq9EMIKH6hleCZ2j hmrcNE9WuWP2Bu5ZEEgiIjwtK5K9NU4S3RqF5qVPc3uNFMlIoAxlGtzUyCxTasUA 1m7fpPawsmrDjRH6UtaVKXw9hRjw2Qb/1eAx+vFwEeBiznuEuwH39jpeHkciyHcx ORULb4GilEd986m/2WSKIpa549of5PGPDX6wjBBBXm69tPni2HbsMVHEl+gKJkLp 3fefpYSvFPHbR9UeP5I9sd7tjas2T+EFONSXppkfcU+P/thiyFPvU8OIp1ZlaZzp jNmOY4zmzs0bNpg55Gc8TNbtVb++xp/6VkpEI2xt6F0yqR16XqcZmouQpywaq//H y9Pv7+4k3v0wQGP2fRVMgWaQNK13sOH4qWP7SxHeMiaRfWRoA+EqxSx6UfoqCBZi YZHo13fN+nSYygWHvh+H8LBaqPbk2O+qeSJA3DKhtSbMUmKX/GCT6IxGuGhD6cgh E4XBmUP9HK6hyE214ElWN2rXo/qxYVkbZjG/SGp2vWGou01H8ChTjvcsGmb1JOwY V5xYtvSTVThMNH79K2GauzTKQZmVux/EH7Penb2okT/LdQSZSyIDFy/HvnjsBvbL 4WqW4vrYjAW/w/TKKL5i =nh8a -----END PGP SIGNATURE----- --KGRu7WxDW0E86NnQ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111223115931.GY1771>