Project

General

Profile

Source tree restructuring » History » Version 1

Version 1/3 - Next » - Current version
Jessica Mack, 06/07/2015 01:43 AM


Source tree restructuring

Summary

During the makefile cleanup, there was some mention on the mailing list about a possible 'phase 2' - the cleanup of the source tree.
I've got a scratchbook file with an idea of how the source tree could look like. I thought it might be good to share that and use it as a basis for discussion.
I invite people to add comments to the 'detailed description' below.

Owners

Interested Parties

  • Name (Affiliation)
  • Name (Affiliation)
  • Name

Current Status

Detailed Description

/Makefile.am
/configure.ac
/autogen.sh
/AUTHORS, /COPYING, /README, etc
/SubmittingPatches
/Doxyfile
/ChangeLog
/CodingStyle
/PendingReleaseNotes

/contrib -- scripts and extras (/admin, /keys, /share, /src/script, /src/bash_completion)
/contrib/dist -- distro stuff for rpm/debian/etc (including /udev, /src/upstart)
/contrib/m4 -- autotools scripts
/contrib/qa
/contrib/wireshark
/contrib/gtest
/contrib/libs3
/contrib/pybind

/examples

/doc

/rados -- librados (installed as librados.so)
/rados/include -- exports will become "#include <ceph/rados/XYZ>" 
/rados/src
/rados/test

/rbd -- librbd (installed as librbd.so)
/rbd/include -- exports will become "#include <ceph/rbd/XYZ>" 
/rbd/src
/rbd/fuse
/rbd/test

# Uses msgr, messages, osdc, and osdmap/mdsmap/monmap
# Maybe better to also put MonClient in here?
/client -- libclient (install as libcephclient.so, or only use as convenience lib?)
/client/include -- exports will become "#include <ceph/client/XYZ>" 
/client/src
/client/test

# Or is this nicer in /client/cephfs, /client/hadoop, /client/cephfs_jni or something?
/cephfs -- libcephfs (installed as libcephfs.so)
/cephfs/include -- exports will become "#include <ceph/cephfs/XYZ>" 
/cephfs/src
/cephfs/jni
/cephfs/hadoop
/cephfs/test

/rgw -- librgw (future, install as librgw.so)
/rgw/include -- exports will become "#include <ceph/rgw/XYZ>" 
/rgw/src
/rgw/test

# Do we want this standalone? It's also used by cephfs, rgw, 
/auth -- libauth (install as libcephauth.so, or only use as convenience lib?)
/auth/src
/auth/test

# Do we want os + backends standalone, or shall we put it in /ceph/os ?
/os -- libos (install as libcephos.so, or only use as convenience lib?)
/os/include -- exports will become "#include <ceph/os/XYZ>" 
/os/test

# This can be completely standalone
/crush -- libcrush (installed as libcrush.so)
/crush/include -- exports will become "#include <ceph/crush/XYZ>" 
/crush/src
/crush/tools -- like crushtool
/crush/test

/ceph
/ceph/include -- exports will become "#include <ceph/XYZ>" 
/ceph/common
/ceph/src -- main daemons like ceph_mon.cc etc
/ceph/mon -- current /src/mon/*
/ceph/mds
/ceph/osd
/ceph/osdc
/ceph/msg -- should this be here?
/ceph/test
/ceph/tools

# What about msg/messages? And events?

Work items

Coding tasks

  1. Task 1
  2. Task 2
  3. Task 3

Build / release tasks

  1. Task 1
  2. Task 2
  3. Task 3

Documentation tasks

  1. Task 1
  2. Task 2
  3. Task 3

Deprecation tasks

  1. Task 1
  2. Task 2
  3. Task 3