tests/kernel: Add a test for CONFIG_MULTITHREADING=n

This is a feature Ben added so you could use Zephyr's arch layer to
bootstrap things like bootloaders without sucking in the whole kernel.
And it's worked until now.

But we never had a test for it, and I just broke it with the scheduler
rework.  Add a trivial test just to make sure this continues to link
and run.  Longer term it would be nice to have some kind of size
metric here to guarantee that the feature stays lean and doesn't pull
in needless code.

Signed-off-by: Andy Ross <[email protected]>

Author: Andy Ross

tests/kernel/threads/no-multithreading/CMakeLists.txt

@@ -0,0 +1,5 @@
+include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake NO_POLICY_SCOPE)
+project(NONE)
+
+FILE(GLOB app_sources src/*.c)
+target_sources(app PRIVATE ${app_sources})

tests/kernel/threads/no-multithreading/prj.conf

@@ -0,0 +1,5 @@
+CONFIG_ZTEST=y
+CONFIG_MULTITHREADING=n
+CONFIG_USERSPACE=n
+CONFIG_BT=n
+CONFIG_USB=n

tests/kernel/threads/no-multithreading/src/main.c

@@ -0,0 +1,20 @@
+/*
+ * Copyright (c) 2018 Intel Corporation
+ *
+ * SPDX-License-Identifier: Apache-2.0
+ */
+#include <zephyr.h>
+#include <ztest.h>
+
+/* The only point to CONFIG_MULTITHREADING=n is to use Zephyr's
+ * multiplatform toolchain, linkage and boostrap integration to arrive
+ * here so the user can run C code unimpeded.  In general, we don't
+ * promise that *any* Zephyr APIs are going to work properly, so don't
+ * try to test any.  That means we can't even use the ztest suite
+ * framework (which spawns threads internally).
+ */
+void test_main(void)
+{
+	TC_PRINT("It works\n");
+	TC_END_REPORT(TC_PASS);
+}

tests/kernel/threads/no-multithreading/testcase.yaml

@@ -0,0 +1,8 @@
+tests:
+  kernel.threads.no-multithreading:
+    tags: core
+    filter: not CONFIG_SMP
+
+    # Pulls in GPIO by default, which needs missing APIs (why?!), but
+    # its headers won't build with GPIO disabled.
+    platform_exclude: galileo