Discussion of a platform-independent OpenZFS code repository at the 2013 OpenZFS Developer Summit. http://www.open-zfs.org/wiki/OpenZFS_Developer_Summit

1. Platform-independent code repository

2. Goals
● Simplify getting changes into every platform
● Simplify SPLs (Solaris Porting Layers on
non-illumos platforms)
● All code in OpenZFS repo can be pulled by
all platforms with zero local modifications
○ This might be a stretch for day one

3. What code is included?
● Must be testable on any platform
● Must be testable in userland
● Today, can include most of:
○ SPA, DMU, DSL, ZAP, ZIL
○ tested by ztest
● With userland ioctl work, can also include:
○ send/recv, diff, allow, zfs_ioctl.c, /sbin/zfs, libzfs
○ tested by testrunner test suite
● Makefiles?
● First goal: everything except:
○
ZPL, ZVOL, and vdev_disk.c

4. Interfaces consumed
● All interfaces consumed by code in repo
should be well-defined
● All functions should be prefixed with zk_*
○ zk_mutex_enter, zk_kstat_install, zk_kmem_alloc
● Repo will include code that implements
these in userland (libzpool)
● Each platform (including illumos) will have a
“porting layer” that implements these for their
kernel

5. Specific examples
● ZK_SYSCTL_UQUAD
○ declares tunables in FreeBSD style
○ other platforms can ignore
● zk_sleep_until
○ instead of cv_timedwait_hires(t_delay_cv, …
●

6. What libs are included?
● To implement zk_* in userland, what about
the libraries:
○ libnvpair, libavl, libumem
● Include them in the Repo?
● Require them as external dependencies?

7. Procedures
● What code changes can be integrated?
○ Testing requirements?
■ Must be tested in one kernel?
■ Must add tests to test suite?
○ Review requirements?
■ pre- vs post- push review?
■ who must review?
○ Usefulness requirements?
○ Platform neutrality requirement? (“#ifdef LINUX”)
● What is the process?
● How are changes documented?
○ bug report? commit comment? commit notes?

8. Proposed Procedure
● All changes must be reviewed before
integration
● Changes should be tested in userland and in
one kernel
● Relatively few committers initially (~3-10)
○ committers responsible for ensuring code is
reviewed adequately by subject area experts
○ expected to be available to review code
● Changes documented in bug reports

9. Coding rules
What constraints need to be applied?
● Small stack allocations (linux has 8k stack)
○ create bigger stacks for sync/zio threads?
●
●
●
●
language (C99)
compiler (gcc & clang?)
lint-clean (w/which flags?)
strict lock order (FreeBSD’s WITNESS)
○ must be checkable in userland on other platforms

10. Tools
● Github
○ but not pull requests
● Code review
○ Github? ReviewBoard? Webrev?
● Bug Tracking
○ Github? Jira?
● Makefiles
○ Each platform seems to have their own

11. How to get there from here
● Create repo with files identical to illumos
● Reduce diffs between repo and other distros
○ upstream (to repo) or revert changes
○ e.g. add freebsd tunable declarations
○ e.g. convert linux to C99
● Convert to zk_* wrappers gradually
● Testrunner on libzpool
○ finish userland ioctl work
○ add dd-like API to userland