11

Click here to load reader

OpenZFS code repository

Embed Size (px)

DESCRIPTION

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

Citation preview

Page 1: OpenZFS code repository

Platform-independent code repository

Page 2: OpenZFS code repository

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

Page 3: OpenZFS code repository

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

Page 4: OpenZFS code repository

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

Page 5: OpenZFS code repository

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, …

Page 6: OpenZFS code repository

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?

Page 7: OpenZFS code repository

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?

Page 8: OpenZFS code repository

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

Page 9: OpenZFS code repository

Coding rulesWhat 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

Page 10: OpenZFS code repository

Tools● Github

○ but not pull requests● Code review

○ Github? ReviewBoard? Webrev?● Bug Tracking

○ Github? Jira?● Makefiles

○ Each platform seems to have their own

Page 11: OpenZFS code repository

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