Re: [PATCH] OpenSolaris/ZFS: C++ compatibility

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?
> > 
> > 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).
> 
> 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).
> 
> 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++.
> 
> 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.

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
pjd_at_FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!