Draft initial namespace to organize and access various elements of th…

…e experimental

tool-chain and framework in a principled manner

Merge branch 'feature-experimental-toolchain-draftnamespace' into develop

* feature-experimental-toolchain-draftnamespace: (33 commits)
  experimental-toolchain: notate uberSpark front-end tools namespace
  experimental-toolchain: add README within tools namespace
  experimental-toolchain: minor fixes to stay consistent with terminology throughout the namespace
  experimental-toolchain: cleanup defunct vault/ folder
  experimental-toolchains: rename targets namespace to platforms
  experimental-toolchain: revise platform configuration namespace documentation
  experimental-tool: move existing call sentinel into new namespace within sentinels
  experimental-toolchain: revise sentinel namespace top-level documentation
  experimental-tools: begin refactoring sentinels namespace
  experimental-toolchain: refine hwm namespace documentation
  experimental-toolchain: add basic documentation for loaders namespace
  experimental-toolchain: finish fleshing out basic loaders namespace
  experimental-toolchain: continue refactoring loaders namespace by relocating linux-um loader into appropriate namespace heirarchy
  experimental-toolchain: begin refactoring loaders namespace
  experimental-toolchain: revise README.rst within loaders namespace to document namespace high-level organization
  experimental-toolchain: move README.md within loaders namespace to README.rst
  experimental-toolchain: add base documentation of uobjcoll namespace
  experimental-toolchain: instantiate uobjcoll namespace
  experimental-toolchain: plug in base documentation for uobjs namespace
  experimental-toolchain: add uobjs namespace
  ...

.vscode/settings.json

@@ -0,0 +1,3 @@
+{
+    "restructuredtext.confPath": ""
+}

src/experimental-toolchain/README.rst

@@ -0,0 +1,17 @@
+root namespace for uberspark experimental toolchain for next generation stand-alone uobject build, 
+verification, and runtime attestation...
+
+author: amit vasudevan (amitvasudevan@acm.org)
+
+``README.rst``
+    this file
+
+``bsconfigure.sh``
+    (bash) shell script to generate autoconf configure script
+
+``configure.ac``
+    autoconf configuration template
+
+``Makefile.in``
+    top-level Makefile template parameterized by autoconf
+

src/experimental-toolchain/bridges/README.rst

@@ -0,0 +1,12 @@
+namespace for uberobject verification and compilation bridges along with integration shims
+
+``vbridge``
+    verification bridges to interface with verification tools to verify uobjects (e.g., frama-c, coq)
+
+``ccbridge``
+    compilation bridges to interface with compiler tools to compile uobject 
+    sources (e.g., gcc, clang, compcert)
+
+``knitshims``
+    support trusses for specific coss build systems (e.g., gnu make, cmake) to tie in and interface 
+    with uobjects

src/experimental-toolchain/bridges/ccbridge/README.rst

@@ -0,0 +1,2 @@
+namespace for compilation bridges to interface with compiler tools to compile uobject 
+sources (e.g., gcc, clang, compcert)

src/experimental-toolchain/bridges/knitshims/README.rst

@@ -0,0 +1,2 @@
+namespace for support trusses for specific coss build systems (e.g., gnu make, cmake) to tie in and interface 
+with uobjects

src/experimental-toolchain/bridges/vbridge/README.rst

@@ -0,0 +1,2 @@
+namespace for verification bridges to interface with verification tools to verify 
+uobjects (e.g., frama-c, coq)

src/experimental-toolchain/hwm/README.rst

@@ -0,0 +1,14 @@
+namespace for uberSpark hardware model specifications toward verifying uobject mediated/accessed platform
+hardware states
+
+``cpu``
+    various supported architecture and CPU specific instruction level hardware modeling,
+    including a general device interface abstraction to integrate device level modeling
+
+``device``
+    various supported devices and their internal state modeling (e.g., what the device does 
+    in response to a particular input). interacts with ``cpu`` via a general device interface abstraction
+
+``platform``
+    device agnostic platform-level modeling. e.g., for pc platform BIOS and option 
+    ROM functionality.

src/experimental-toolchain/hwm/cpu/README.rst

@@ -0,0 +1,34 @@
+namespace for various supported architecture and CPU specific instruction level hardware 
+modeling, including a general device interface abstraction to integrate device level modeling
+
+general form of a namespace node here:
+
+``cpu-arch``
+    where cpu-arch is the name of the processor architecture (e.g., arm, x86)
+
+    ``cpu-subarch``
+        where cpu-subarch is a processor architecture revision/qualifier (e.g., armv8_32, x86_32)
+
+        ``cpu-type``
+            where cpu-type is the processor type specific (e.g., generic, cortex_a53, intel, amd)
+
+example namespace node:
+
+``arm``
+    ARM architecture
+    contains namespace development recipe (e.g., armv8_32-cortex_a53)
+
+    ``common``
+        common ARM cpu architecture
+
+    ``armv8_32``
+        ARMv8 32-bit cpu architecture
+
+        ``generic``
+            generic ARMv8 32-bit cpu architecture
+
+        ``cortex_a53``
+            cortext_a53 specific ARMv8 32-bit cpu architecture
+
+    ``armv7_32``
+        ARMv7 32-bit cpu architecture

src/experimental-toolchain/hwm/device/README.rst

@@ -0,0 +1,17 @@
+namespace for various supported devices and their internal state modeling 
+(e.g., what the device does in response to a particular input). interacts 
+with ``cpu`` namespace via a general device interface abstraction
+
+namespace organization:
+
+``device-class``
+    type of function that the device performs (e.g., network controller)
+
+    ``device-subclass``
+        specific functionality of the device (e.g., ethernet controller)
+
+        ``device-vendor``
+            vendor name of the device (e.g., marvell)
+
+            ``device-id``
+                specific id or instance of the device (e.g., marvel ppv2)

src/experimental-toolchain/hwm/platform/README.rst

@@ -0,0 +1,22 @@
+namespace for cpu and device agnostic platform-level modeling. 
+e.g., for pc platform, the BIOS and option ROM functionality.
+
+example namespace node:
+
+``pc``
+    PC computing platform
+    contains namespace development recipe (e.g., pc_32 or pc_64)
+
+    ``common``
+        common pc platform modeling
+
+    ``pc_16``
+        pc 16-bit computing platform
+
+    ``pc_32``
+        pc 32-bit computing platform
+        includes logic within ``common``
+
+    ``pc_64``
+        pc 64-bit computing platform
+        includes logic within ``common``

src/experimental-toolchain/include/README.rst

@@ -0,0 +1,4 @@
+namespace for common headers that are included by both coss legacy code (for uobject integration) as well as
+uobjects themselves.
+
+

src/experimental-toolchain/loaders/README.rst

@@ -0,0 +1,10 @@
+namespace for uberSpark operating environment runtime loaders, which are used to load uobj collections
+
+namespace organization:
+
+``os``
+    namespace for OS specific uobj runtime loaders (e.g., linux user mode)
+
+``baremetal``
+    namespace for baremetal environment uobj runtime loaders (e.g., grub, uboot)
+

src/experimental-toolchain/loaders/baremetal/README.rst

@@ -0,0 +1,22 @@
+namespace for baremetal environment uobj runtime loaders (e.g., grub, uboot)
+
+example namespace node organization:
+
+``vcldr``
+    namespace for vccore based baremetal loader
+    it can have its unique set of inputs (e.g., uobj collection manifest, vcldr version pinning etc.)
+    it will produce its unique set of outputs  (e.g., consolidated image)
+    it will select one or more of the following components based on inputs
+
+    ``common`` 
+        this folder will contain vcldr version and platform agnostic logic
+
+    ``vx.y.z``
+        version x.y.z specific 
+
+    ``platform``
+        this folder will contain subfolders that has to exist within ``targets/``
+        for example, below:
+
+        ``rpi3_32``
+            for raspberry pi3 32-bit platform

src/experimental-toolchain/loaders/os/README.rst

@@ -0,0 +1,8 @@
+namespace for OS specific uobj runtime loaders (e.g., linux user mode)
+
+namespace organization:
+
+``linux``
+    namespace for linux OS specific uobj runtime loaders (e.g., linux user and kernel mode)
+
+

src/experimental-toolchain/loaders/os/linux/README.rst

@@ -0,0 +1,22 @@
+namespace for linux OS specific uobj runtime loaders (e.g., linux user and kernel mode)
+
+namespace organization:
+
+``backends``
+    backend abstraction implementations for generic as well as specific linux kernel versions
+
+``common``
+    commond linux support routines
+
+``kmode``
+    linux kernel mode loader; uses backend abstraction
+
+``umode``
+    linux user mode loader; uses backend abstraction
+
+
+namespace build:
+
+- it can have its unique set of inputs (e.g., uobj collection manifest, version pinning etc.)
+- it will produce its unique set of outputs  (e.g., static library, executable)
+- it will select one or more of the following components based on inputs

src/experimental-toolchain/platforms/README.rst

@@ -0,0 +1,15 @@
+namespace for supported hardware computing platform configurations.
+
+platform configuration rules:
+
+- platform includes set of cpus and devices
+- platform can have different cpus of different architectures
+- devices and cpus are independent and can be part of multiple platforms
+
+namespace node organization:
+
+``platform``.json
+    for each ``platform`` within ``hwm/platform`` which includes the aforementioned binding rules for 
+    platform specific cpus and devices
+
+

src/experimental-toolchain/sentinels/README.rst

@@ -0,0 +1,27 @@
+namespace for various supported uobj and uobj collection sentinels.
+
+the name space organization is as follows:
+
+``platform``
+    this namespace node organization is the same as that of ``hwm/platform`` namespace node with
+    entries corresponding to the development recipes
+
+``cpu``
+    this namespace node organization is the same as that of ``hwm/cpu`` namespace node with entries
+    corresponding to the development receipies
+
+the leaf nodes of the above namespace tree contain a sentinel node with the following 
+general organization:
+
+``sentinel_name``
+    name of the sentinel (e.g., call) and has the following files:
+    - sentinel implementation
+    - sentinel manifest which includes sentinel size, platform and cpu details and dependencies
+
+example namespace node:
+
+``call`` sentinel running on a generic platform and a generic x86 32-bit cpu architecture will be
+housed under:
+
+``cpu/x86_32/generic/call``
+

src/experimental-toolchain/tools/README.rst

@@ -0,0 +1,3 @@
+namespace for uberspark experimental toolchain front-end tools 
+
+author: amit vasudevan (amitvasudevan@acm.org)