OpenZFS code repository

  • 519 views
Uploaded on

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

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
519
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
8
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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