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.

Andrew