In message: <20070503182623.GA591@hairylemon.org>
            Andrew Doran <ad@NetBSD.org> writes:
: On Thu, May 03, 2007 at 07:25:32PM +0200, Juan RP wrote:
: 
: > On Thu, 3 May 2007 08:43:51 -0400
: > Oliver Gould <ogould@olix0r.net> wrote:
: > 
: > > Hello Everyone-
: > > 
: > > I'm starting to set up a NetBSD/SolarisExpress dual-boot system to
: > > develop and test ZFS on this summer.  I'll eventually be able to create
: > > zpools in NetBSD and then test them on Solaris; and if the summer goes
: > > /really/ well, vice versa.
: > > 
: > > My question is: what NetBSD version should I target?  I'll want to take
: > > advantage of any new APIs (newlock2, etc), though I won't want things to
: > > change under me over the summer, either.  Are other API changes expected
: > > in the near future that I should be aware of, or is a current -current
: > > just fine?
: > > 
: > > Any thoughts/advice on the matter?
: > 
: > Yes, if I'm not wrong zfs uses atomic ops. There's a branch called
: > thorpej-atomic (Jason R. Thorpe is one of your mentors), you'll have to
: > take a look at the primitives implemented there and use them appropiately.
: > 
: > This is just to avoid having new code, if you can use the atomic API
: > from this branch, it will be easier.
: 
: ZFS also likely makes use of memory barriers, which the thorpej-atomic
: branch provides, too. So I also recommend basing your work off the
: thorpej-atomic branch.
: 
: Note that there are some interface differences between NetBSD's
: synchronization primitives and Solaris': I'm not sure of the exact
: details so you'll need to check. You can paper over most of them
: using macros.
: 
: - Solaris' rw_init() takes arguments, NetBSD's does not. The arguments
:   can safely be ignored.
: 
: - I think Solaris has something like a MUTEX_HELD() macro. For NetBSD
:   that translates to mutex_owned().
: 
: - NetBSD's mutex_init() takes 3 arguments. Solaris takes more IIRC.
:   As long as you are initializing mutexes of the type MUTEX_DEFAULT or
:   MUTEX_ADAPTIVE there should be no problem, just ditch the additional
:   arguments and pass IPL_NONE as the ipl.
: 
: - NetBSD's cv_init() probably takes different arguments. It's likely that
:   the Solaris equivalent takes a name string, but from what I remember it's
:   also likely to be always specified as NULL. You might want to specify the
:   name as "zfscv" or something like that.
: 
: - Solaris' cv_wait_sig(), cv_timedwait(), and cv_timedwait_sig() have
:   a different convention for the return value. On NetBSD they return zero
:   (for a normal wakeup) or a Unix error number if not. On Solaris (if I
:   remember correctly) it's zero for a normal wakeup, and 1 or -1 for other
:   outcomes.

There's also a whole slew of Solaris interfaces that ZFS uses.  In the
FreeBSD port, a number of files were imported from OpenSolaris and/or
compatibility shims written to minimize differences to the upstream
source.  It may make more sense to do that than to put a lot of work
into the ZFS sources only to havve to redo it for newer versions.

In fact, it might be illustrative to see how the FreeBSD port was done
in general.  No sense in completely reinventing the wheel.

Warner