]> git-server-git.apps.pok.os.sepia.ceph.com Git - ceph.git/commit
ErasureCode: complete plugin loader unit tests 605/head
authorLoic Dachary <loic@dachary.org>
Thu, 19 Sep 2013 07:28:14 +0000 (09:28 +0200)
committerLoic Dachary <loic@dachary.org>
Thu, 19 Sep 2013 07:47:53 +0000 (09:47 +0200)
commit4c9497f9be0560e0aed4b97d5969001c27a58203
tree2858201dbd58581467d944d2a2bdaffe72de0c3e
parent7324931d5ec8e57ff9d5ae4e5700a1a479f5a6bb
ErasureCode: complete plugin loader unit tests

* TestErasureCodePluginExample.cc is renamed to TestErasureCodePlugin.cc
  because it's not limited to the example which is really used to
  support tests rather than being tested.

* Bugous plugins are added to exhibit failures and enable the unit tests
  to check they are handled as expected

  ErasureCodePluginFailToInitialize : the entry point returns != 0
  ErasureCodePluginFailToRegister : the plugin registry is not updated
  ErasureCodePluginMissingEntryPoint : the shared library has no entry
  point

* It would be difficult to prove that the mutex protecting against
  multiple loads actually does what it is expected to because of the
  lack of thread introspection functions such as : tell me if this
  thread is waiting on this mutex. A simpler approach is chosen : create
  a thread that blocks forever when loading ( that's what the delay in
  the example plugin is for ) and then check that the lock has indeed
  been acquired. Since this mutex is merely about making sure that only
  one thread at a time runs this sequence of code, it's probably enough.

Signed-off-by: Loic Dachary <loic@dachary.org>
src/test/Makefile.am
src/test/osd/ErasureCodePluginFailToInitialize.cc [new file with mode: 0644]
src/test/osd/ErasureCodePluginFailToRegister.cc [new file with mode: 0644]
src/test/osd/ErasureCodePluginMissingEntryPoint.cc [new file with mode: 0644]
src/test/osd/TestErasureCodePlugin.cc [new file with mode: 0644]
src/test/osd/TestErasureCodePluginExample.cc [deleted file]