OpenZFS code repository


Published on

Discussion of a platform-independent OpenZFS code repository at the 2013 OpenZFS Developer Summit.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

OpenZFS code repository

  1. 1. Platform-independent code repository
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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