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

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.

> 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.

> 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.

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.

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?

Thanks,
Justin