Re: CVS commit: src/common/include/prop

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sun, Dec 07, 2008 at 09:45:35AM +0000, Andrew Doran wrote:
> On Fri, Dec 05, 2008 at 04:20:10PM +0100, Manuel Bouyer wrote:
> 
> > > > > > On Fri, Dec 05, 2008 at 01:11:41PM +0000, Andrew Doran wrote:
> > > > > > > Log Message:
> > > > > > > Avoid conflicts with ZFS.
> 
> > it's ugly.
> 
> I agree.
> 
> > It will also lead to interesting bugs in the future, say, when we'll want
> > to use proplib inside zfs
> 
> It's unlikely because Sun has a problib analogue which zfs uses (libnvpair).
> 
> > (or when something happens to use both proplib and zfs headers).
> 
> It could happen with our mount() syscall or some disk stuff but I think we
> can isolate those safely.

The problem is that someone has to remmeber about this when adding a
new call or a new tool.

> 
> > I can't see why proplib would be more at fault than zfs for this
> > conflict
> 
> It's not proplib's fault per-se. The conflict occurs in the ZFS kernel code
> and not user space code. It arises because libprob.h is included in many of
> our kernel headers, and it clashes with symbols from the ZFS headers.

So no userland header will #define _PROPLIB_ZFS_CONFLICT ?

> 
> Excluding 3 or 4 source files, I have all of ZFS compiling and linking and
> this is the only conflict that I have not been able to resolve another way.
> Everything else is handled with cpp tricks and glue functions. This one I
> could not fix with cpp.
> 
> > and why zfs can't be changed.
> 
> I have avoided changing the ZFS source wherever possible because the more
> our copy diverges from Sun's, the more time we will have to invest to
> maintain and support it.

that's fine but in this case maybe changing the zfs type/defines is
reasonable, because it conflicts with another widely-used subsystem in
netbsd.

> 
> We could possibly provide a problib_types.h header that provides enough
> types for our header files, but does not automatically expose other symbols.

That won't be easy for this one as the type is an enum, and the list of
possible value is part of the type AFAIK. I also wonder if this could lead
to a different size of prop_type_t on some of our platforms.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--