Updates

onlp/implementors/apis.md

@@ -0,0 +1,16 @@
+# Platform APIs
+
+## OID Specific APIs
+
+* [chassisi](http://opencomputeproject.github.io/OpenNetworkLinux/onlp/implementors/chassisi)
+* [fani](http://opencomputeproject.github.io/OpenNetworkLinux/onlp/implementors/fani)
+* [psui](http://opencomputeproject.github.io/OpenNetworkLinux/onlp/implementors/psui)
+* [thermali](http://opencomputeproject.github.io/OpenNetworkLinux/onlp/implementors/thermali)
+* [sfpi](http://opencomputeproject.github.io/OpenNetworkLinux/onlp/implementors/sfpi)
+* [ledi](http://opencomputeproject.github.io/OpenNetworkLinux/onlp/implementors/ledi)
+* [modulei](http://opencomputeproject.github.io/OpenNetworkLinux/onlp/implementors/modulei)
+* [generici](http://opencomputeproject.github.io/OpenNetworkLinux/onlp/implementors/generici)
+* [attributei](http://opencomputeproject.github.io/OpenNetworkLinux/onlp/implementors/attributesi)
+
+## System APIs
+* [platformi](http://opencomputeproject.github.io/OpenNetworkLinux/onlp/implementors/platformi)

onlp/implementors/attributei.md

@@ -0,0 +1 @@
+# attributei

onlp/implementors/chassisi.md

@@ -0,0 +1 @@
+# chassisi

onlp/implementors/fani.md

@@ -0,0 +1 @@
+# fani

onlp/implementors/generici.md

@@ -0,0 +1 @@
+# generici

onlp/implementors/getting_started.md

@@ -0,0 +1,56 @@
+# ONLP Platform Implementation APIs
+
+## Getting Started
+
+Adding ONLP support for your platform involves implementing all required interfaces and any optional interfaces your hardware might support.
+For those that like to browse the code early all available interfaces are defined [here](https://github.com/opencomputeproject/OpenNetworkLinux/tree/ONLPv2/packages/base/any/onlp/src/onlp/module/inc/onlp/platformi).
+
+## ONLP Implementation Subsystems
+
+* platformi - platform identification, selection, and management
+* chassisi - Your chassis OID implementation.
+* fani - Your fan OID implementation.
+* psui - Your PSU OID implementation.
+* thermali - Your thermal OID implementation.
+* sfpi - Your SFP OID implementation.
+* ledi - Your LED OID implementation.
+* attributei - You implementation of any OID attributes.
+
+## Initialization
+
+### Platform Discovery and Assignement
+
+When the ONLP layer initializes the first thing it will do is ask your implementation the name of the platform for which it is written. You must implement ```onlp_platformi_get()``` to return the name of your platform implementation.
+For example, if your ONL platform is ```x86-64-fantastinet-fnt9000-r0``` then this is what your ```onlp_platformi_get()``` should return.
+
+The ONLP layer compares this to the current platform if it matches then initialization proceeds.
+
+#### A note about multiple platform support in your implementation
+While most implementations will only support a single platform, you may have a scenario in which there are multiple subplatforms supported by your implementation -- usually because there are little or no software visible differences.
+
+In this case you might return something like ```x86-64-fantastinet-fnt9000-rX``` because you want to support both the r0 and r1 versions of your platform. If the name returned by ```onlp_platformi_get()``` does not match the current platform then we will ask you to configure yourself for the current platform
+by calling ```onlp_platformi_set("x86-64-fantastinet-fnt9000-r0")```. If this functions returns successfully then we assume you have configured yourself correctly and will continue with initialization.
+
+### Module Software Initialization
+
+After platform assignment is complete all of the following SW init functions will be called prior to any other entry points:
+
+* ```onlp_chassisi_sw_init()```
+* ```onlp_modulei_sw_init()```
+* ```onlp_thermali_sw_init()```
+* ```onlp_fani_sw_init()```
+* ```onlp_psui_sw_init()```
+* ```onlp_ledi_sw_init()```
+* ```onlp_sfpi_sw_init()```
+* ```onlp_generici_sw_init()```
+
+All of these functions are optional. You only need to implement the vectors which do something useful. The default implementations of these vectors just return successfully.
+
+If any of your SW init functions fail then initialization fails. This is not an expected condition.
+
+### API Operations
+
+What happens after initialization is up to the application. Once your modules are initialized then their entry points will be called by the ONLP layer in response to application requests.
+
+---
+[Next: ONLP Platform Implementation APIs](http://opencomputeproject.github.io/OpenNetworkLinux/onlp/applications/api)

onlp/implementors/index.md

@@ -1 +1,72 @@
-Implementors
+# ONLP Platform Implementations
+
+Please Note: All Platform Implementations should read the [ONLP Applications API documentation](http://opencomputeproject.github.io/OpenNetworkLinux/onlp/applications/) first to familiarize yourself with the API concepts you will be implementing.
+
+The ONL software architecture is designed to support multiple platforms with the same image and distribution. The ONLP Application API provides unified access to all of these different platforms at runtime.
+
+## ONLP Architecture
+
+The ONLP Common Application API (collectively defined [here](https://github.com/opencomputeproject/OpenNetworkLinux/tree/ONLPv2/packages/base/any/onlp/src/onlp/module/inc/onlp)) is used by system applications and provides common middleware for each system and is the gateway to your implementation.
+You implementation libraries contain similar, but reduced functionality necessary to support the features needed by the platform and the upper layer software.
+
+### Platform Shared Libraries
+
+The ONLP Platform Implementation Code is arranged as a shared library written and built specifically for a platform (or family of platforms) by the platform integrator.
+The correct shared library for the current platform is selected at early boot time and the correct library links are created.
+
+All of this is handled automatically by the ONL core boot code.
+
+### API Organization
+
+Your APIs are a similar subset of the functionality defined in the application layer.
+
+All APIs for the platform implementor are defined [here](https://github.com/opencomputeproject/OpenNetworkLinux/tree/ONLPv2/packages/base/any/onlp/src/onlp/module/inc/onlp/platformi).
+The following sections will go into more detail on the requires for each subsystem.
+
+### A Note on API Exclusion
+
+The ONLP common layer provides complete exclusion between all calls to the platform implementation across the entire system. This removes the need to manage any concurrency or reentrance issues in your into your code.
+You can be guaranteed that no other thread or process in the entire system is accessing your ONLP driver calls at the same time.
+
+This has high value for platform drivers that wish to implement some or all of their functionality in user space. The API exclusion feature means you can reprogram mux trees and access resources for the entirely of the time your entry point is executing.
+
+**You do no need and in general should not add additional locking mechanisms to your code.**
+
+### A Note on OIDs and API Parameters
+
+While the signatures of your entry points are roughly equivalent to the upper layer which proxies it for you it is important to note that the upper layer cleans the incoming OID (of type ```onlp_oid_t```) and sends you only the ID (of type ```onlp_oid_id_t```) as a convenience. No need to extract the ID from the OID.
+The upper layer never calls your code until after it has validated that the OID passed to the API is of the correct type.
+
+You should however verify that the ID passed to you refers to a valid object where necessary. Objects may become invalid before the caller has learned it.
+
+### A Note on Required and Optional Functions
+
+The ONLP API represents a union of all defined functionality. Not all features will be available on all platforms.
+
+You do not need to provide all entry points -- only the entry points you support. It is not necessary to provide a stub for every function.
+The shared library infrastructure provides additional weak definitions for every possible entry point that return ```ONLP_STATUS_E_UNSUPPORTED```.
+
+This architecture allows new functions to be added to the API without requiring updates to existing platforms. If the platform supports the concept of the new feature then it would be preferable that it get updated but if the platform does not or will not support the new feature then there is no need to modify that platform's implementation in any way.
+
+**Please do not put empty stubs in your implementation and rely instead on the stubs you automatically inherit. It makes the code cleaner, smaller, and more obvious.***
+
+### A Note about Hardware and Software Initialization
+
+Every subsystem supports the concept of Hardware and Software Initialization. The distinction is important and should be note by the platform implementor:
+
+#### The Software Init Routine
+
+Each subsystem has an (optional) routine called ```onlp_<name>_sw_init()```. This function will be called prior to any other call into the same module.
+This function must initialize the local software and datastructures for operation but it ***must not change the hardware in any way***. This is simple preparing the software to begin operating on a running system.
+
+Each subsystem has an (optional) routine called ```onlp_<name>_sw_denit()``` for the purposes of completeness and testing.
+
+#### The Hardware Init Routine
+
+Each subsystem has an (optional) routine called ```onlp_<name>_hw_init()```. This routine will be called at early boot time to perform any one-time initialization needed to prepare the system for operation.
+ONLP Applications do not and should not typically call this routine but leave it to the boot time infrastructure.
+
+As ONLP Applications are allowed to spawn as multiple processes at any time and in any number the separation of initialization of the local software state and of the platform hardware itself must be cleanly maintained.
+
+---
+[Next: Getting Started](http://opencomputeproject.github.io/OpenNetworkLinux/onlp/applications/getting_started)

onlp/implementors/ledi.md

@@ -0,0 +1 @@
+# ledi

onlp/implementors/modulei.md

@@ -0,0 +1 @@
+# modulei

onlp/implementors/platformi.md

@@ -0,0 +1 @@
+# platformi

onlp/implementors/psui.md

@@ -0,0 +1 @@
+# chassis

onlp/implementors/sfpi.md

@@ -0,0 +1 @@
+# chassis

onlp/implementors/thermali.md

@@ -0,0 +1 @@
+# thermali