Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

OpenZFS code repository

1,238 views

Published on

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

http://www.open-zfs.org/wiki/OpenZFS_Developer_Summit

Published in: Technology
  • Be the first to comment

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

×