0
Platform-independent code repository
Goals
● Simplify getting changes into every platform
● Simplify SPLs (Solaris Porting Layers on
non-illumos platforms)
● A...
What code is included?
● Must be testable on any platform
● Must be testable in userland
● Today, can include most of:
○ S...
Interfaces consumed
● All interfaces consumed by code in repo
should be well-defined
● All functions should be prefixed wi...
Specific examples
● ZK_SYSCTL_UQUAD
○ declares tunables in FreeBSD style
○ other platforms can ignore

● zk_sleep_until
○ ...
What libs are included?
● To implement zk_* in userland, what about
the libraries:
○ libnvpair, libavl, libumem

● Include...
Procedures
● What code changes can be integrated?
○ Testing requirements?
■ Must be tested in one kernel?
■ Must add tests...
Proposed Procedure
● All changes must be reviewed before
integration
● Changes should be tested in userland and in
one ker...
Coding rules
What constraints need to be applied?
● Small stack allocations (linux has 8k stack)
○ create bigger stacks fo...
Tools
● Github
○ but not pull requests

● Code review
○ Github? ReviewBoard? Webrev?

● Bug Tracking
○ Github? Jira?

● Ma...
How to get there from here
● Create repo with files identical to illumos
● Reduce diffs between repo and other distros
○ u...
Upcoming SlideShare
Loading in...5
×

OpenZFS code repository

661

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
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
661
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
11
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Transcript of "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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×