tree: 8100bc7e1cbcd83f2a82cedd77e2b45f24f656eb [path history] [tgz]
  1. bad-syscall/
  2. c11-condvar/
  3. c11-mutex/
  4. c11-thread/
  5. channel/
  6. clock/
  7. condition-generic/
  8. elf-tls/
  9. event-pair/
  10. fifo/
  11. futex/
  12. handle-close/
  13. handle-info/
  14. handle-transfer/
  15. handle-wait/
  16. interrupt/
  17. job/
  18. memory-mapping/
  19. object-child/
  20. object-info/
  21. pager/
  22. port/
  23. process/
  24. profile/
  25. pthread/
  26. pthread-barrier/
  27. pthread-tls/
  28. resource/
  29. socket/
  30. stack/
  31. sync-completion/
  32. sync-condition/
  33. sync-mutex/
  34. threads/
  35. time/
  36. vmar/
  37. vmo/
  38. BUILD.gn
  39. main.c
  40. README.md
zircon/system/utest/core/README.md

utest/core

The “core” tests exist for one main purpose: To test basic functionality when things like devmgr aren't working.

If the kernel is told to run core-tests instead of devmgr, these tests will run without any userspace device manager, device drivers, io plumbing, etc.

Example usage

./scripts/run-zircon-x64 -c userboot=bin/core-tests
./scripts/run-zircon-arm64 -c userboot=bin/core-tests

Notes

The tests here are for “core” functionality (channels, etc.), but not all “core” functionality can go here. For example, you can‘t start a process in your test with launchpad because core tests are for when that functionality isn’t working. Core tests can't use fdio and launchpad uses fdio.

Since these tests can't use fdio core/main.c stubs out the needed functions from fdio.