Subject: soc zfs: namespace collision between proplib and compat code
To: None <>
From: Oliver Gould <>
List: tech-userlevel
Date: 08/15/2007 16:14:59
Hello All-

A not-insignificant amount of FreeBSD-compatible Solaris userland code
(from which I am porting ZFS utilities) relies on boolean_t.  In order
to accommodate this code, I added the following (or something
thereabout) to the ZFS compatibility layer's sys/types.h:

  #ifndef _KERNEL
  typedef enum {false, true}	boolean_t; 

However, for code that also includes sys <sys/disk.h>, there is a
conflict with the boolean_t defined in <prop/prop_object.h>.

  typedef      int     boolean_t;

This conflict stops compilation in libzfs (which is a critical backend
to the relevant userland tools).

I'm not really sure of the best way to mitigate this.  I can modify all
of the Solaris/FreeBSD instances of boolean_t to be bool_t, but this
entails maintaining a larger patchset which is, of course, undesirable.

Otherwise, it seems (to me) like a good idea to change proplib's
boolean_t to e.g. prop_boolean_t -- or, better yet, bool_t.  While
there's probably a good reason why proplib doesn't use bool_t already,
the namespace collision seems likely to be problematic outside of ZFS,

Or, if code in the NetBSD source tree is actually going to continue
using boolean_t, perhaps its definition could be moved somewhere more
common to other code?

My dirty hack for now is to include <prop/prop_object.h> from the compat
sys/types.h, but I don't like that as a general solution.  Am I
otherwise stuck changing all of the Solaris code away from boolean_t?
Any other suggestions?

  - Oliver