From owner-freebsd-current@FreeBSD.ORG Sat Feb 5 22:07:13 2011 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB47A106564A for ; Sat, 5 Feb 2011 22:07:13 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 747F68FC15 for ; Sat, 5 Feb 2011 22:07:13 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id E66D045DD8; Sat, 5 Feb 2011 23:07:11 +0100 (CET) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 624CB45B36; Sat, 5 Feb 2011 23:07:06 +0100 (CET) Date: Sat, 5 Feb 2011 23:06:46 +0100 From: Pawel Jakub Dawidek To: "Justin T. Gibbs" Message-ID: <20110205220646.GZ2035@garage.freebsd.pl> References: <4D4C3F89.50700@scsiguy.com> <20110205153920.GS2035@garage.freebsd.pl> <4D4DC2E8.60901@scsiguy.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ynll37MX3Fmyj3VY" Content-Disposition: inline In-Reply-To: <4D4DC2E8.60901@scsiguy.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: current@FreeBSD.org Subject: Re: [PATCH] OpenSolaris/ZFS: C++ compatibility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 22:07:14 -0000 --ynll37MX3Fmyj3VY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 05, 2011 at 02:36:40PM -0700, Justin T. Gibbs wrote: > On 2/5/2011 8:39 AM, Pawel Jakub Dawidek wrote: > > On Fri, Feb 04, 2011 at 11:03:53AM -0700, Justin T. Gibbs wrote: > >> The attached patch is sufficient to allow a C++ program to use libzfs. > >> The motivation for these changes is work I'm doing on a ZFS fault > >> handling daemon that is written in C++. SpectraLogic's intention > >> is to return this work to the FreeBSD project once it is a bit more > >> complete. > >> > >> Since these changes modify files that come from OpenSolaris, I want to= be > >> sure I understand the project's policies regarding divergence from > >> the vendor before I check them in. All of the changes save one should > >> be trivial to merge with vendor changes and I will do that work for the > >> v28 import. Is there any reason I should not commit these changes? > >=20 > > Now that OpenSolaris is dead we don't have to be so strict with keeping > > the diff against vendor small at all cost. I'd prefer not to modify > > vendor code whenever possible so it is easier for us to cooperate with > > IllumOS (we already took ome code from them). >=20 > Perhaps IllumOS will accept these changes back? As I mentioned in the > change descriptions included with the patch, the header files already > show the intention of providing C++ support (extern "C" blocks), they > just don't quite deliver. The changes shouldn't be controversial. Sure. To be clear: I'm not against those changes, I think they are worth it. And getting IllumOS to accept them back is definitely a good idea. > > Me and my company are also interested in fault management daemon > > (although not restricted to ZFS, but a more general purpose mechanism > > like FMA in Solaris). >=20 > We have talked internally about this at Spectra too. Since we don't have > BSD licensed nvpair code, we've thought of using Google protocol buffers > to allow extensible encoding of fault data. The GP implementation is > MIT licensed and looks like it might be less cumbersome to use than > nvpairs. For the first release of our product, however, we are just > making due with the string data that devctl provides. I've developed similar API during HAST work, maybe it is a good starting point? src/sbin/hastd/nv.{c,h}. > > My question would be are there any chances you may > > be convinced to use plain C? With C we might be able to help, but not > > with C++. >=20 > The core FMA support needs to be reasonably accessible from C code of > course (fully functional and not cumbersome to use). But we should > allow FMA agents to be coded in whatever language is convenient to the > developer. The project may only be able to accept agents in C (and I'm > voting for C++ too) into it's distribution, but that policy should not > drive us to make the FMA architecture hard to access from shell, python, > ruby, or some other language. Yes, agents should not be limited to one language. I wouldn't be surprised is the majority of agents will be shell scripts. > The reason I chose C++ for this task is that devd, the source of the > events I process, already requires C++ so using C++ in zfsd doesn't > impose any new requirements on the system. Zfsd, like even the C > kernel of FreeBSD is coded in an object oriented fashion, but its > much cleaner to implement this type of design in a language that > inherently supports object oriented concepts. Could I rewrite all > that I have in C? Sure, but there would have to be some compelling > reasons to offset the reduction in clarity and maintainability such > a change would cause. Hmm, so zfsd will receive events from devd? I'm in opinion that we should let devd alone. In my initial port I used devd, because it was closest match, but if we want to clean it up, we shouldn't go through devd. For example ZFS v28 can report whole binary blocks where checksum doesn't match and passing those through devd would be cumbersome. > Is your inability to help on a C++ version of this code due to distaste > for C++ or just a lack of experience with it? The latter. I'm sure there are many committers that are fluent in C++, but all of them know C. I was under impression that Warner implemented devd in C++ also as a kind of experiment, which nobody really followed. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --ynll37MX3Fmyj3VY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk1NyfUACgkQForvXbEpPzQy+ACfX/AR8ObmbmdLKaCMMjm6RqpL njgAmwUJGrzXih2kdSXWeMTTFNM23CKy =umLH -----END PGP SIGNATURE----- --ynll37MX3Fmyj3VY--