Align with doc structure

This commit is contained in:
suvendhu 2023-01-09 16:04:10 +05:30
parent 0ef6169d86
commit be4929300e
31 changed files with 14486 additions and 1021 deletions

1
.gitignore vendored
View file

@ -49,4 +49,5 @@ CMakeFiles/
cmake_install.cmake
install_manifest.txt
*.so
docs/index.md

1021
README.md

File diff suppressed because it is too large Load diff

5
docs/.pages Normal file
View file

@ -0,0 +1,5 @@
title: "DOCS"
nav:
- "guide"
- "..."

Binary file not shown.

File diff suppressed because it is too large Load diff

After

Width:  |  Height:  |  Size: 330 KiB

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

File diff suppressed because it is too large Load diff

After

Width:  |  Height:  |  Size: 329 KiB

Binary file not shown.

Binary file not shown.

Binary file not shown.

124
docs/css/colors.css Executable file
View file

@ -0,0 +1,124 @@
////
/// Copyright (c) 2016-2021 Martin Donath <martin.donath@squidfunk.com>
///
/// Permission is hereby granted, free of charge, to any person obtaining a
/// copy of this software and associated documentation files (the "Software"),
/// to deal in the Software without restriction, including without limitation
/// the rights to use, copy, modify, merge, publish, distribute, sublicense,
/// and/or sell copies of the Software, and to permit persons to whom the
/// Software is furnished to do so, subject to the following conditions:
///
/// The above copyright notice and this permission notice shall be included in
/// all copies or substantial portions of the Software.
///
/// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
/// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
/// FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
/// THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
/// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
/// FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
/// DEALINGS
////
// ----------------------------------------------------------------------------
// Rules
// ----------------------------------------------------------------------------
// Color variables
:root {
// Default color shades
--md-default-fg-color: hsla(0, 0%, 0%, 0.87);
--md-default-fg-color--light: hsla(0, 0%, 0%, 0.54);
--md-default-fg-color--lighter: hsla(0, 0%, 0%, 0.32);
--md-default-fg-color--lightest: hsla(0, 0%, 0%, 0.07);
--md-default-bg-color: hsla(0, 0%, 100%, 1);
--md-default-bg-color--light: hsla(0, 0%, 100%, 0.7);
--md-default-bg-color--lighter: hsla(0, 0%, 100%, 0.3);
--md-default-bg-color--lightest: hsla(0, 0%, 100%, 0.12);
// Primary color shades
--md-primary-fg-color: hsla(#{hex2hsl($clr-indigo-500)}, 1);
--md-primary-fg-color--light: hsla(#{hex2hsl($clr-indigo-400)}, 1);
--md-primary-fg-color--dark: hsla(#{hex2hsl($clr-indigo-700)}, 1);
--md-primary-bg-color: hsla(0, 0%, 100%, 1);
--md-primary-bg-color--light: hsla(0, 0%, 100%, 0.7);
// Accent color shades
--md-accent-fg-color: hsla(#{hex2hsl($clr-indigo-a200)}, 1);
--md-accent-fg-color--transparent: hsla(#{hex2hsl($clr-indigo-a200)}, 0.1);
--md-accent-bg-color: hsla(0, 0%, 100%, 1);
--md-accent-bg-color--light: hsla(0, 0%, 100%, 0.7);
// Light theme (default)
> * {
// Code color shades
--md-code-fg-color: hsla(200, 18%, 26%, 1);
--md-code-bg-color: hsla(0, 0%, 96%, 1);
// Code highlighting color shades
--md-code-hl-color: hsla(#{hex2hsl($clr-yellow-a200)}, 0.5);
--md-code-hl-number-color: hsla(0, 67%, 50%, 1);
--md-code-hl-special-color: hsla(340, 83%, 47%, 1);
--md-code-hl-function-color: hsla(291, 45%, 50%, 1);
--md-code-hl-constant-color: hsla(250, 63%, 60%, 1);
--md-code-hl-keyword-color: hsla(219, 54%, 51%, 1);
--md-code-hl-string-color: hsla(150, 63%, 30%, 1);
--md-code-hl-name-color: var(--md-code-fg-color);
--md-code-hl-operator-color: var(--md-default-fg-color--light);
--md-code-hl-punctuation-color: var(--md-default-fg-color--light);
--md-code-hl-comment-color: var(--md-default-fg-color--light);
--md-code-hl-generic-color: var(--md-default-fg-color--light);
--md-code-hl-variable-color: var(--md-default-fg-color--light);
// Typeset color shades
--md-typeset-color: var(--md-default-fg-color);
// Typeset `a` color shades
--md-typeset-a-color: var(--md-primary-fg-color);
// Typeset `mark` color shades
--md-typeset-mark-color: hsla(#{hex2hsl($clr-yellow-a200)}, 0.5);
// Typeset `del` and `ins` color shades
--md-typeset-del-color: hsla(6, 90%, 60%, 0.15);
--md-typeset-ins-color: hsla(150, 90%, 44%, 0.15);
// Typeset `kbd` color shades
--md-typeset-kbd-color: hsla(0, 0%, 98%, 1);
--md-typeset-kbd-accent-color: hsla(0, 100%, 100%, 1);
--md-typeset-kbd-border-color: hsla(0, 0%, 72%, 1);
// Typeset `table` color shades
--md-typeset-table-color: hsla(0, 0%, 0%, 0.12);
// Admonition color shades
--md-admonition-fg-color: var(--md-default-fg-color);
--md-admonition-bg-color: var(--md-default-bg-color);
// Footer color shades
--md-footer-fg-color: hsla(0, 0%, 100%, 1);
--md-footer-fg-color--light: hsla(0, 0%, 100%, 0.7);
--md-footer-fg-color--lighter: hsla(0, 0%, 100%, 0.3);
--md-footer-bg-color: hsla(0, 0%, 0%, 0.87);
--md-footer-bg-color--dark: hsla(0, 0%, 0%, 0.32);
}
// Shadow depth 1
--md-shadow-z1:
0 #{px2rem(4px)} #{px2rem(10px)} hsla(0, 0%, 0%, 0.05),
0 0 #{px2rem(1px)} hsla(0, 0%, 0%, 0.1);
// Shadow depth 2
--md-shadow-z2:
0 #{px2rem(4px)} #{px2rem(10px)} hsla(0, 0%, 0%, 0.1),
0 0 #{px2rem(1px)} hsla(0, 0%, 0%, 0.25);
// Shadow depth 3
--md-shadow-z3:
0 #{px2rem(4px)} #{px2rem(10px)} hsla(0, 0%, 0%, 0.2),
0 0 #{px2rem(1px)} hsla(0, 0%, 0%, 0.35);
}

2601
docs/css/extra.css Executable file

File diff suppressed because it is too large Load diff

28
docs/css/iopsys-white.svg Normal file
View file

@ -0,0 +1,28 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 24.2.3, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
<svg version="1.1" id="Lager_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
viewBox="0 0 460 84" style="enable-background:new 0 0 460 84;" xml:space="preserve">
<style type="text/css">
.st0{fill:#FFFFFF;}
</style>
<g>
<g>
<rect x="2.8" y="4.3" class="st0" width="16.7" height="76.1"/>
<path class="st0" d="M88.8,3C65.3,3,48.3,20.8,48.3,42.4v0.2c0,21.6,16.9,39.1,40.3,39.1c23.5,0,40.6-17.7,40.6-39.4v-0.2
C129.1,20.5,112.3,3,88.8,3z M111.6,42.6c0,13-9.4,23.7-22.8,23.7c-13.5,0-23-10.9-23-23.9v-0.2c0-13,9.4-23.7,22.8-23.7
c13.5,0,23.1,10.9,23.1,23.9v0.2H111.6z"/>
<path class="st0" d="M271.4,34.9c-13.2-3.4-16.4-5-16.4-10v-0.2c0-3.7,3.4-6.6,9.8-6.6s13,2.8,19.8,7.5l8.7-12.6
c-7.7-6.2-17.2-9.7-28.3-9.7c-15.5,0-26.6,9.1-26.6,22.9v0.2c0,15.1,9.9,19.4,25.2,23.3c12.7,3.3,15.3,5.4,15.3,9.7v0.2
c0,4.5-4.1,7.2-11,7.2c-8.7,0-15.9-3.6-22.7-9.2l-9.9,11.9c9.1,8.2,20.8,12.2,32.3,12.2c16.4,0,27.9-8.5,27.9-23.6v-0.2
C295.5,44.5,286.8,38.9,271.4,34.9z"/>
<polygon class="st0" points="347.3,34.9 329.1,4.3 309.5,4.3 338.8,50.4 338.8,80.4 355.5,80.4 355.5,50.1 384.8,4.3 365.7,4.3
"/>
<path class="st0" d="M432.2,34.9c-13.2-3.4-16.4-5-16.4-10v-0.2c0-3.7,3.4-6.6,9.8-6.6s13,2.8,19.8,7.5l8.7-12.6
c-7.7-6.2-17.2-9.7-28.3-9.7c-15.6,0-26.6,9.1-26.6,22.9v0.2c0,15.1,9.9,19.4,25.2,23.3c12.7,3.3,15.3,5.4,15.3,9.7v0.2
c0,4.5-4.1,7.2-11,7.2c-8.7,0-15.9-3.6-22.7-9.2l-9.9,11.9c9.1,8.2,20.8,12.2,32.3,12.2c16.4,0,27.9-8.5,27.9-23.6v-0.2
C456.3,44.5,447.6,38.9,432.2,34.9z"/>
<path class="st0" d="M186,4.3h-31.5v15.3h30c8.5,0,13.8,4.1,13.8,11.7v0.2c0,6.6-5,11.7-13.4,11.7h-30.4v37.2h16.9V58.3h12.9
c17.3,0,31.1-9.2,31.1-27.1V31C215.5,15.2,204.3,4.3,186,4.3z"/>
</g>
</g>
</svg>

After

Width:  |  Height:  |  Size: 1.8 KiB

17
docs/css/pdf.css Normal file
View file

@ -0,0 +1,17 @@
@page {
size: a4 portrait;
margin: 25mm 10mm 25mm 10mm;
counter-increment: page;
font-family: 'Madera', 'Lucida Sans Unicode', 'Lucida Grande', sans-serif;
white-space: pre;
color: grey;
@top-left {
content: '© 2022 IOPSYS';
}
@top-center {
content: string(chapter);
}
@top-right {
content: 'Page ' counter(page);
}
}

4
docs/guide/.pages Normal file
View file

@ -0,0 +1,4 @@
title: "Developer Guides"
nav:
- "..."

View file

@ -34,7 +34,7 @@ root@iopsys-44d43771aff0:~#
```
For those cron jobs it is required to give the handler script to be executed which is in our case [bbf_activate_handler.sh](/scripts/bbf_activate_handler.sh). And, it is located under '/usr/share/bbfdm/' in the device.
For those cron jobs it is required to give the handler script to be executed which is in our case [bbf_activate_handler.sh](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/scripts/bbf_activate_handler.sh). And, it is located under '/usr/share/bbfdm/' in the device.
## Cron job specification
@ -62,7 +62,7 @@ For each cron job related to the activated firmware, it is needed to define it a
## Activate Handler script
As described, we create a cron job for each TimeWindow in order to activate the required firmware within a specified time by running the [bbf_activate_handler.sh](/scripts/bbf_activate_handler.sh) handler script.
As described, we create a cron job for each TimeWindow in order to activate the required firmware within a specified time by running the [bbf_activate_handler.sh](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/scripts/bbf_activate_handler.sh) handler script.
In fact, the aim of this script is to manage firmware images based on the **mode** and the other passed arguments.
@ -73,22 +73,22 @@ For these modes and based on the firmware bank id, the required firmware image w
### 2. How to handle 'WhenIdle' mode:
Definition of WhenIdle may vary for each deployment and customer, to make it customizable [bbf_check_idle.sh](/scripts/bbf_check_idle.sh) script is used. It is assumed that customer shall overwrite this file using customer-config to match with there requirement.
Definition of WhenIdle may vary for each deployment and customer, to make it customizable [bbf_check_idle.sh](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/scripts/bbf_check_idle.sh) script is used. It is assumed that customer shall overwrite this file using customer-config to match with there requirement.
In this mode, [bbf_activate_handler.sh](/scripts/bbf_activate_handler.sh) script calls this script [bbf_check_idle.sh](/scripts/bbf_check_idle.sh) to determine the idle state of the device. [bbf_activate_handler.sh](/scripts/bbf_activate_handler.sh) assumes the device as idle if the exit status of the above script is 0, or if the [bbf_check_idle.sh](/scripts/bbf_check_idle.sh) is not present in the predefined path "ACTIVATE_HANDLER_FILE@dmcommon.h".
In this mode, [bbf_activate_handler.sh](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/scripts/bbf_activate_handler.sh) script calls this script [bbf_check_idle.sh](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/scripts/bbf_check_idle.sh) to determine the idle state of the device. [bbf_activate_handler.sh](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/scripts/bbf_activate_handler.sh) assumes the device as idle if the exit status of the above script is 0, or if the [bbf_check_idle.sh](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/scripts/bbf_check_idle.sh) is not present in the predefined path "ACTIVATE_HANDLER_FILE@dmcommon.h".
If the exit code from the idle script is zero then firmware image can be activated. Otherwise, it has to wait for next time slot which is defined by 'RETRY_TIME' variable.
> Note1: The time slot is set through 'RETRY_TIME' variable which is defined under '/usr/share/bbfdm/bbf_activate_handler.sh' script.
> Note2: The exit status of the script [bbf_check_idle.sh](/scripts/bbf_check_idle.sh) is important because based on it, the '[bbf_activate_handler.sh](/scripts/bbf_activate_handler.sh) script will decide whether the image can be activated or not.
> Note2: The exit status of the script [bbf_check_idle.sh](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/scripts/bbf_check_idle.sh) is important because based on it, the '[bbf_activate_handler.sh](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/scripts/bbf_activate_handler.sh) script will decide whether the image can be activated or not.
> Note3: Algorithm/Logic to determine the Idle state of device is out of scope of this document and it is expected that users overwrite this script with the logic to determine the same in actual deployment.
> Note4: If 1 or more TimeWindow.{i}.Mode is set to 'WhenIdle' and all of them fails to get the idle state. The latest TimeWindow instance will force the device to activate the firmware image.
> Note5: If the idle script [bbf_check_idle.sh](/scripts/bbf_check_idle.sh) not present in the pre-defined path "ACTIVATE_HANDLER_FILE@dmcommon.h", then the device is assumed to be in ideal state and the firmware shall be activated instantly.
> Note5: If the idle script [bbf_check_idle.sh](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/scripts/bbf_check_idle.sh) not present in the pre-defined path "ACTIVATE_HANDLER_FILE@dmcommon.h", then the device is assumed to be in ideal state and the firmware shall be activated instantly.
> Note6: It is very likely that TimeWindow with 'WhenIdle' mode might not find any suitable Idle state, in that case firmware shall not be activated. If users/operators want to make sure that firmware gets activated at the end, then they can add a TimeWindow with 'AnyTime/Immediate' mode at the end, to activate the firmware.
@ -101,7 +101,7 @@ If the exit code from the idle script is zero then firmware image can be activat
* If TimeWindow.{i}.Start is set, TimeWindow.{i}.End and TimeWindow.{i}.Mode become mondatory.
* The firmware activation is done by [bbf_activate_handler.sh](/scripts/bbf_activate_handler.sh) script as per the defined Mode in TimeWindow, but if the TimeWindow is not defined, it will activate the requested FirmwareImage instance immediately.
* The firmware activation is done by [bbf_activate_handler.sh](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/scripts/bbf_activate_handler.sh) script as per the defined Mode in TimeWindow, but if the TimeWindow is not defined, it will activate the requested FirmwareImage instance immediately.
* If the customer wants to be sure that the required firmware is getting activated at the end then they can define the TimeWindow.{i}.Mode as 'AnyTime' or 'Immediately' in the last TimeWindow instance.

View file

@ -0,0 +1,12 @@
# How to expose datamodel over ubus directly with the help of libbbf APIs
`Libbbf_ubus` is the library that helps in exposing the datamodel over ubus directly using libbbf_api.
Application using `libbbf_ubus`, shall not use the `libbbfdm` library because all needed operations from `libbbfdm` library has been internally handled in `libbbf_ubus`.
To identify the mechanism of exposing datamodel directly over ubus please refer to the sample code [dmtest.c](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/test/dynamicdm_ubus_test/bbf_ubus.c)
For more info you can see the schemas at:
- Raw schema [link](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/schemas/dmtest.json)
- Markdown schema [link](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/schemas/dmtest.md)

483
docs/guide/dynamic_dm.md Normal file
View file

@ -0,0 +1,483 @@
# BBFDM Dynamic Object/Parameter/Operate/Event
`bbfdm` library allows all applications installed on the box to import its own Data Model parameters at run time in two formats:
- **Shared library**
- **JSON files**
## 1. Shared library via external package
The application should bring its shared library under **'/usr/lib/bbfdm/'** path that contains the sub tree of **Objects/Parameters** and the related functions **Get/Set/Add/Delete/Operate**. The new added objects, parameters and operates will be automatically shown by icwmpd and uspd/obuspa.
Each library should contains the Root table: **“tDynamicObj”**
### DynamicObject definition
The “tDynamicObj” table contains entries of **DM_MAP_OBJ** structure.
The **DM_MAP_OBJ** structure contains three arguments:
| Argument | Description |
| ---------------- | ------------------------------------------------------------------------------------------------------------- |
| `parentobj` | A string of the parent object name. Example “Device.IP.Diagnostics.”, “Device.DeviceInfo”, “Device.WiFi.Radio.” |
| `nextobject` | Pointer to a **DMOBJ** array which contains a list of the child objects |
| `parameter` | Pointer to a **DMLEAF** array which contains a list of the child parameters |
For the other tables, they are defined in the same way as the Object and Parameter definition described above.
> Note1: Shared library can only add vendor or standard objects that are not implemented by `libbbfdm`
> Note2: Shared library is not allowed to overwrite objects/parameters
- For more examples on the external packages, you can see these links: [BulkData](https://dev.iopsys.eu/iopsys/bulkdata/-/blob/master/datamodel.c), [XMPP](https://dev.iopsys.eu/iopsys/xmppc/-/blob/master/datamodel.c)
### 2. JSON File via external package
The application should bring its JSON file under **'/etc/bbfdm/json/'** path with **UCI** and **UBUS** mappings. The new added parameters will be automatically shown by icwmpd and uspd/obuspa.
#### Some examples on JSON Definition
**1. Object without instance:**
```bash
"Device.CWMP.": {
"type": "object",
"protocols": [
"cwmp",
"usp"
],
"array": false,
"access": false
}
```
**2. Object with instance:**
- **UCI command:** uci show wireless | grep wifi-device
```bash
"Device.X_IOPSYS_EU_Radio.{i}.": {
"type": "object",
"protocols": [
"cwmp",
"usp"
],
"array": true,
"access": true,
"mapping": {
"type": "uci",
"uci": {
"file": "wireless",
"section": {
"type": "wifi-device"
},
"dmmapfile": "dmmap_wireless"
}
}
}
```
- **UBUS command:** ubus call dsl status | jsonfilter -e @.line
```bash
"Device.DSL.Line.{i}.": {
"type": "object",
"protocols": [
"cwmp",
"usp"
],
"array": true,
"access": false,
"mapping": {
"type": "ubus",
"ubus": {
"object": "dsl",
"method": "status",
"args": {},
"key": "line"
}
}
}
```
**3. Parameter under object with instance:**
- **UCI option command:** uci get wireless.@wifi-device[0].country
- **@i:** is the number of instance object
```bash
"Country": {
"type": "string",
"protocols": [
"cwmp",
"usp"
],
"read": true,
"write": true,
"mapping": [
{
"type" : "uci",
"uci" : {
"file" : "wireless",
"section" : {
"type": "wifi-device",
"index": "@i-1"
},
"option" : {
"name" : "country"
}
}
}
]
}
```
- **UCI list command:** uci get urlfilter.@profile[0].whitelist_url
- **@i:** is the number of instance object
```bash
"WhitelistURL": {
"type": "string",
"version": "2.14",
"read": true,
"write": true,
"protocols": [
"cwmp",
"usp"
],
"list": {
"datatype": "string"
},
"mapping": [
{
"type": "uci",
"uci": {
"file": "urlfilter",
"section": {
"type": "profile",
"index": "@i-1"
},
"list": {
"name": "whitelist_url"
}
}
}
]
}
```
- **UBUS command:** ubus call wifi status | jsonfilter -e @.radios[0].noise
- **@i:** is the number of instance object
```bash
"Noise": {
"type": "int",
"protocols": [
"cwmp",
"usp"
],
"read": true,
"write": false,
"mapping": [
{
"type" : "ubus",
"ubus" : {
"object" : "wifi",
"method" : "status",
"args" : {},
"key" : "radios[@i-1].noise"
}
}
]
}
```
**4. Parameter without instance:**
- **UCI option command:** uci get cwmp.cpe.userid
```bash
"Username": {
"type": "string",
"protocols": [
"cwmp",
"usp"
],
"read": true,
"write": true,
"mapping": [
{
"type" : "uci",
"uci" : {
"file" : "cwmp",
"section" : {
"type": "cwmp",
"name": "cpe"
},
"option" : {
"name" : "userid"
}
}
}
]
}
```
- **UCI list command:** uci get urlfilter.globals.blacklist_url
- **@i:** is the number of instance object
```bash
"BlacklistURL": {
"type": "string",
"read": true,
"write": true,
"protocols": [
"cwmp",
"usp"
],
"list": {
"datatype": "string"
},
"mapping": [
{
"type": "uci",
"uci": {
"file": "urlfilter",
"section": {
"name": "globals"
},
"list": {
"name": "blacklist_url"
}
}
}
]
}
```
- **UBUS command:** ubus call system info | jsonfilter -e @.uptime
```bash
"Uptime": {
"type": "unsignedInt",
"protocols": [
"cwmp",
"usp"
],
"read": true,
"write": false,
"mapping": [
{
"type" : "ubus",
"ubus" : {
"object" : "system",
"method" : "info",
"args" : {},
"key" : "uptime"
}
}
]
}
```
- **UBUS command:** ubus call system info | jsonfilter -e @.memory.total
```bash
"Total": {
"type": "unsignedInt",
"protocols": [
"cwmp",
"usp"
],
"read": true,
"write": false,
"mapping": [
{
"type" : "ubus",
"ubus" : {
"object" : "system",
"method" : "info",
"args" : {},
"key" : "memory.total"
}
}
]
}
```
**5. Parameter to map another data model Object:**
- **UCI option command:** uci get urlfilter.@filter[0].profile
- **linker_obj** is the path name of an object that is stacked immediately below this object
```bash
"Profile": {
"type": "string",
"read": true,
"write": true,
"protocols": [
"cwmp",
"usp"
],
"mapping": [
{
"type": "uci",
"uci": {
"file": "urlfilter",
"section": {
"type": "filter",
"index": "@i-1"
},
"option": {
"name": "profile"
}
},
"linker_obj": "Device.{BBF_VENDOR_PREFIX}URLFilter.Profile."
}
]
}
```
**6. Object with Event and Operate command:**
```bash
{
"Device.X_IOPSYS_Test.": {
"type": "object",
"protocols": [
"cwmp",
"usp"
],
"array": false,
"access": false,
"Push!": {
"type": "event",
"version": "2.13",
"protocols": [
"usp"
],
"data": {
"type": "string",
"read": true,
"write": true,
"version": "2.13",
"protocols": [
"usp"
]
}
},
"Status()": {
"type": "command",
"async": true,
"version": "2.12",
"protocols": [
"usp"
],
"input": {
"Option": {
"type": "string",
"read": "true",
"write": "true",
"protocols": [
"usp"
]
}
},
"output": {
"Result": {
"type": "string",
"read": "true",
"write": "false",
"protocols": [
"usp"
]
}
},
"mapping": [
{
"type": "ubus",
"ubus": {
"object": "test",
"method": "status"
}
}
]
}
}
}
```
- **UBUS command:** ubus call usp operate '{"path":"Device.X_IOPSYS_Test.", "action":"Status()", "input":{"Option":"Last"}}'
```bash
{
"Results": [
{
"path": "Device.X_IOPSYS_Test.Status()",
"result": [
{
"Result": "Success"
}
]
}
]
}
```
- **UBUS command:** ubus call usp get_supported_dm
```bash
{
"parameters": [
{
"parameter": "Device.X_IOPSYS_Test.Push!",
"type": "xsd:event",
"in": [
"data"
]
},
...
]
}
```
- **UBUS command:** ubus call usp list_operate
```bash
{
"parameters": [
{
"parameter": "Device.X_IOPSYS_Test.Status()",
"type": "async",
"in": [
"Option"
],
"out": [
"Result"
]
},
...
]
}
```
> Note1: JSON File can only add vendor or standard objects that are not implemented by `libbbfdm`
> Note2: JSON File is not allowed to overwrite objects/parameters
> Note3: Set, Add, Delete methods are only allowed for uci mapping. therefore for ubus mapping, only Get method is authorized
> Note4: Each object definition in JSON file must begin with "Device." and should have the full parent path if it is under another object
- For more examples on JSON files, you can see these links: [X_IOPSYS_EU_MCPD](https://dev.iopsys.eu/feed/broadcom/-/blob/devel/mcpd/files/etc/bbfdm/json/X_IOPSYS_EU_MCPD.json), [UserInterface](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/test/files/etc/bbfdm/json/UserInterface.json), [X_IOPSYS_EU_Dropbear](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/test/files/etc/bbfdm/json/X_IOPSYS_EU_Dropbear.json), [X_IOPSYS_EU_TEST](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/test/files/etc/bbfdm/json/X_IOPSYS_EU_TEST.json)

View file

@ -1,5 +1,6 @@
# Firewall
Aim of this document to explain the TR181 firewall datamodel parameter mappings with firewall and network uci.
# TR181 Firewall datamodel mapping
Aim of this document is to explain the TR181 firewall datamodel parameter mappings with firewall and network uci.
In TR-181 firewall definition, we have Device.Firewall.Level., Deivce.Firewall.Chain. and Firewall.Chain.{i}.Rules., which does not have one to one mapping with firewall uci sections.

View file

@ -1,4 +1,5 @@
# How to extend Datamodel parameters using Json plugins
It is often required to extend datamodel parameters of the device, extending the datamodel parameters using json plugin is the simplest way for the same.
To extend the datamodel using json plugin, its required to be defined it, as it is defined in `TR181.json` file and then place that json in '/etc/bbfdm/json/' directory of device.

View file

@ -0,0 +1,178 @@
# How to add support for a new Object/Parameter
As mentioned in README, all Data Models are stored in the **'dmtree'** folder. In order to implement a new object/parameter, you need to expand its get/set/add/delete functions and then save them in the right folder.
`bbfdm` library offers a tool to generate templates of the source code from json files placed under **'dmtree/json'**. So, any developer can fill these json files ([tr181](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/dmtree/json/tr181.json) or [tr104](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/dmtree/json/tr104.json)) with mapping field according to UCI, UBUS or CLI commands then generate the source code in C.
```bash
$ ./convert_dm_json_to_c.py
Usage: convert_dm_json_to_c.py <data model name> [Object path]
data model name: The data model(s) to be used, for ex: tr181 or tr181,tr104
Examples:
- convert_dm_json_to_c.py tr181
==> Generate the C code of tr181 data model in datamodel/ folder
- convert_dm_json_to_c.py tr104
==> Generate the C code of tr104 data model in datamodel/ folder
- convert_dm_json_to_c.py tr181,tr104
==> Generate the C code of tr181 and tr104 data model in datamodel/ folder
- convert_dm_json_to_c.py tr181 Device.DeviceInfo.
==> Generate the C code of Device.DeviceInfo object in datamodel/ folder
- convert_dm_json_to_c.py tr104 Device.Services.VoiceService.{i}.Capabilities.
==> Generate the C code of Device.Services.VoiceService.{i}.Capabilities. object in datamodel/ folder
```
Below some examples of **UCI**, **UBUS** or **CLI** mappings:
#### UCI command
- **@Name:** the section name of parent object
- **@i:** is the number of instance object
```bash
"mapping": [
{
"type": "uci",
"uci": {
"file": "wireless",
"section": {
"type": "wifi-device",
"name": "@Name",
"index": "@i-1"
},
"option": {
"name": "disabled"
}
}
}
]
```
#### UBUS command
- **@Name:** the section name of parent object
```bash
"mapping": [
{
"type": "ubus",
"ubus": {
"object": "network.device",
"method": "status",
"args": {
"name": "@Name"
},
"key": "statistics.rx_bytes"
}
}
]
```
#### CLI command:
- **@Name:** the section name of parent object
- **-i:** is the number of arguments command
```bash
"mapping": [
{
"type" : "cli",
"cli" : {
"command" : "wlctl",
"args" : [
"-i",
"@Name",
"bands"
]
}
}
]
```
After building the templates of C source code, a **datamodel** folder will be generated under **'tools'** folder that contains all files related to each object under root "**Device.**"
> Note: You can generate the source code without filling out the mapping field in the JSON file
### Object definition
Each object in the **DMOBJ** table contains the following arguments:
| Argument | Description |
| ------------------- | ---------------------------------------------------------------------------------------------- |
| `OBJ` | A string of the object name. Example “Bridging”, “IP”, “DeviceInfo”, “WiFi” |
| `permission` | The permission of the object. Could be **&DMREAD** or **&DMWRITE**. If it's `&DMWRITE` then we can add/delete instances of this object |
| `addobj` | The function to add new instance under this object. This function will be triggered when the ACS/Controller call AddObject of this object |
| `delobj` | The function to delete instance under this object. This function will be triggered when the ACS/Controller call DeleteObject of an instance of this object |
| `checkdep` | A string of the object dependency, it can be a file("file:/etc/config/network") or an ubus object,method("ubus:network.interface->status"). If it's `NULL` then the object has always appeared in the tree |
| `browseinstobj` | This function allow to browse all instances under this object |
| `nextdynamicobj` | Pointer to the next of **DMOBJ** which contains a list of the child objects using json files, shared libraries and vendor extension |
| `dynamicleaf` | Pointer to the next of **DMLEAF** which contains a list of the child parameters using json files, shared libraries and vendor extension |
| `nextobj` | Pointer to a **DMOBJ** array which contains a list of the child objects |
| `leaf` | Pointer to a **DMLEAF** array which contains a list of the child parameters |
| `linker` | This argument is used for LowerLayer parameters or to make reference to other instance object in the tree |
| `bbfdm_type` | The bbfdm type of the object. Could be **BBFDM_CWMP**, **BBFDM_USP**, **BBFDM_BOTH** or **BBFDM_NONE**.If it's **BBFDM_BOTH** then we can see this object in all protocols (CWMP, USP,...) |
| `uniqueKeys` | The unique key parameters defined for the object. |
### Leaf definition
Each leaf in the **DMLEAF** table can be a **Parameter**, **Command** or **Event**.
#### 1.Parameter definition
| Argument | Description |
| ------------------- | -------------------------------------------------------------------------------------------------- |
| `PARAM` | A string of the parameter name. Example “Enable”, “Status”, “Name” |
| `permission` | The permission of the parameter. Could be **&DMREAD** or **&DMWRITE**.If it's `&DMWRITE` then we can set a value for this parameter |
| `type` | Type of the parameter: **DM_STRING**, **DM_BOOL**, **DM_UNINT**,... |
| `getvalue` | The function which return the value of this parameter |
| `setvalue` | The function which set the value of this parameter |
| `bbfdm_type` | The bbfdm type of the parameter. Could be **BBFDM_CWMP**, **BBFDM_USP**, **BBFDM_BOTH** or **BBFDM_NONE**.If it's **BBFDM_BOTH** then we can see this parameter in all protocols (CWMP, USP,...) |
#### 2.Command definition
| Argument | Description |
| ------------------- | -------------------------------------------------------------------------------------------------- |
| `PARAM` | A string of the command name. Example “IPPing()”, “DownloadDiagnostics()”, “Renew()” |
| `permission` | The permission of the command. Could be **&DMASYNC** or **&DMSYNC**. |
| `type` | Type of the command, It should be **DMT_COMMAND** |
| `getvalue` | The function which return the input, output arguments of the command |
| `setvalue` | The function which call the operation of the command |
| `bbfdm_type` | The bbfdm type of the command. It should be **BBFDM_USP** as long as operate commands are only defined in USP protocol. |
#### 3.Event definition
| Argument | Description |
| ------------------- | -------------------------------------------------------------------------------------------------- |
| `PARAM` | A string of the event name. Example “Boot!”, “Push!”, “Periodic!” |
| `permission` | The permission of the event. It should be **DMREAD** |
| `type` | Type of the event, It should be **DMT_EVENT** |
| `getvalue` | The function which return the parameter arguments of the event |
| `setvalue` | The function which call the operation of the event, It should be **NULL** |
| `bbfdm_type` | The bbfdm type of the event. It should be **BBFDM_USP** as long as events are only defined in USP protocol. |
### Browse definition
The browse function allow to go over all instances of the current object and link them to the data model tree.
In this function, there are two functions that need to be defined:
- function to retrieve the instances: it can be
* `handle_instance` function: allow to retrieve/attribute the instances number/alias from uci config sections depending of the request and the instance mode.
* `handle_instance_without_section` function: allow to attribute the instances number/alias with constant values.
- function to link the instances: we need to call `DM_LINK_INST_OBJ()` function for each instance in order to link the instance to the data model tree. we also need to specify the `data`of this instance level. This `data` could be use later in the sub object and parameters functions (Get/Set/Add/Delete/Operate/Event).
> Note1: the browse function is only developed for multi-instances objects.
> Note2: you can read the next section `BBF API` below to find the definition of the functions used in the browse.
> Note3: you can use [bbf_test plugin](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/test/bbf_test/bbf_test.c) as a reference in order to develop any new object/leaf/browse.

View file

@ -1,4 +1,5 @@
# PBR (Policy based routing)
Aim of this document to explain policy based routing management using TR181 Routing/QoS datamodel parameter mappings with network and qos uci.
In order to enable source based routing, you must first add a new 'Device.Routing.Router.{i}.' object to redirect routes for specific interface to a separate routing table, then configure the policy by adding new instances for 'Device.QoS.Classification.{i}.' object.

239
docs/guide/tools.md Normal file
View file

@ -0,0 +1,239 @@
# BBFDM Tools
BBF tools are written in python3 and has below dependencies.
System utilities: python3-pip, libxml2-utils
```bash
$ sudo apt install -y python3-pip
$ sudo apt install -y libxml2-utils
```
Python utilities: jsonschema, xlwt
```bash
$ pip3 install jsonschema xlwt
```
| Tools | Description |
| ----------------------- |:------------------------------------------------------------:|
|convert_dm_json_to_c.py | Convert json mapping to C code for dynamic plugins library. |
|convert_dm_xml_to_json.py| Convert standart xml to Json format. |
|generate_dm.py | Generate list of supported/un-supported parameters based of json input|
|generate_dm_xml.py | Generate list of supported/un-supported parameters in xml format |
|generate_dm_excel.py | Generate list of supported/un-supported parameters in xls format |
|validate_json_plugin.py | Validate json plugin files for dynamic library or standard data model |
> Note: Currently all the tools needs to be executed in tools directory.
## XML->JSON convertor
It is a [python script](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/tools/convert_dm_xml_to_json.py) to convert Data Model from Broadband Forum XML format to JSON format.
```bash
$ ./convert_dm_xml_to_json.py
Usage: ./convert_dm_xml_to_json.py <tr-xxx cwmp xml data model> <tr-xxx usp xml data model> [Object path]
Examples:
- ./convert_dm_xml_to_json.py tr-181-2-15-0-cwmp-full.xml tr-181-2-15-0-usp-full.xml Device.
==> Generate the json file of the sub tree Device. in tr181.json
- ./convert_dm_xml_to_json.py tr-104-2-0-2-cwmp-full.xml tr-104-2-0-2-usp-full.xml Device.Services.VoiceService.
==> Generate the json file of the sub tree Device.Services.VoiceService. in tr104.json
- ./convert_dm_xml_to_json.py tr-106-1-2-0-full.xml Device.
==> Generate the json file of the sub tree Device. in tr106.json
Example of xml data model file: https://www.broadband-forum.org/cwmp/tr-181-2-15-0-cwmp-full.xml
```
## XML generator
[Python script](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/tools/generate_dm_xml.py) to generator list of supported and un-supported Data Model tree in XML for acs supported format: **Broadband Forum schema** and **HDM**.
```bash
$ ./generate_dm_xml.py -h
usage: generate_dm_xml.py [-h] [-r git^https://dev.iopsys.eu/iopsys/stunc.git^devel] [-v iopsys] [-p X_IOPSYS_EU_] [-d DEVICE_PROTOCOL_DSLFTR069v1] [-m iopsys] [-u 002207] [-c DG400PRIME] [-n DG400PRIME-A]
[-s 1.2.3.4] [-f BBF] [-o datamodel.xml]
Script to generate list of supported and non-supported parameter in xml format
optional arguments:
-h, --help show this help message and exit
-r git^https://dev.iopsys.eu/iopsys/stunc.git^devel, --remote-dm git^https://dev.iopsys.eu/iopsys/stunc.git^devel
Includes OBJ/PARAM defined under remote repositories defined as bbf plugin
-v iopsys, --vendor-list iopsys
Generate data model tree with vendor extension OBJ/PARAM.
-p X_IOPSYS_EU_, --vendor-prefix X_IOPSYS_EU_
Generate data model tree using provided vendor prefix for vendor defined objects.
-d DEVICE_PROTOCOL_DSLFTR069v1, --device-protocol DEVICE_PROTOCOL_DSLFTR069v1
Generate data model tree using this device protocol.
-m iopsys, --manufacturer iopsys
Generate data model tree using this manufacturer.
-u 002207, --manufacturer-oui 002207
Generate data model tree using this manufacturer oui.
-c DG400PRIME, --product-class DG400PRIME
Generate data model tree using this product class.
-n DG400PRIME-A, --model-name DG400PRIME-A
Generate data model tree using this model name.
-s 1.2.3.4, --software-version 1.2.3.4
Generate data model tree using this software version.
-f BBF, --format BBF Generate data model tree with HDM format.
-o datamodel.xml, --output datamodel.xml
Generate the output file with given name
Part of BBF-tools, refer Readme for more examples
```
More examples:
```bash
$ ./generate_dm_xml.py -v iopsys -v openwrt
$ ./generate_dm_xml.py -v iopsys -p X_IOPSYS_EU_ -r git^https://dev.iopsys.eu/iopsys/stunc.git^devel
$ ./generate_dm_xml.py -f HDM -v iopsys -p X_IOPSYS_EU_ -o iopsys.xml
```
> Note: For the remote data model, *git* is the only proto allowed to use in the *generate_dm_xml.py* script. Therefore, if you want to use vendor extensions from a local repository, you must use the *generate_dm.py* script.
## Excel generator
[Python script](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/tools/generate_dm_excel.py) to generate list of supported and un-supported parameters in excel sheet.
```bash
$ ./generate_dm_excel.py -h
usage: generate_dm_excel.py [-h] -d tr181 [-r git^https://dev.iopsys.eu/iopsys/stunc.git^devel] [-v iopsys] [-p X_IOPSYS_EU_] [-o supported_datamodel.xls]
Script to generate list of supported and non-supported parameter in xls format
optional arguments:
-h, --help show this help message and exit
-d tr181, --datamodel tr181
-r git^https://dev.iopsys.eu/iopsys/stunc.git^devel, --remote-dm git^https://dev.iopsys.eu/iopsys/stunc.git^devel
Includes OBJ/PARAM defined under remote repositories defined as bbf plugin
-v iopsys, --vendor-list iopsys
Generate data model tree with vendor extension OBJ/PARAM
-p X_IOPSYS_EU_, --vendor-prefix X_IOPSYS_EU_
Generate data model tree using provided vendor prefix for vendor defined objects
-o supported_datamodel.xls, --output supported_datamodel.xls
Generate the output file with given name
Part of BBF-tools, refer Readme for more examples
```
More examples:
```bash
$ ./generate_dm_excel.py -d tr181 -v iopsys -v openwrt -o datamodel.xls
$ ./generate_dm_excel.py -d tr181 -d tr104 -v iopsys -o datamodel.xls
$ ./generate_dm_excel.py -d tr181 -v iopsys -p X_IOPSYS_EU_ -r git^https://dev.iopsys.eu/iopsys/xmppc.git^devel -o datamodel_iopsys.xls
```
## Validate JSON plugin
It is a [python script](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/tools/validate_json_plugin.py) to validate JSON plugin files for dynamic library or standard data model [TR181](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/dmtree/json/tr181.json), [TR104](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/dmtree/json/tr104.json), etc..
```bash
$ ./tools/validate_json_plugin.py test/files/etc/bbfdm/json/UserInterface.json
$ ./tools/validate_json_plugin.py test/files/etc/bbfdm/json/X_IOPSYS_EU_TEST.json
$ ./tools/validate_json_plugin.py dmtree/json/tr181.json
```
## Data Model generator
This is a pipeline friendly master script to generate the list of supported and un-supported datamodels in xml and xls formats based on provided input in a json file.
Example json file available [here](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/tools/tools_input.json).
```bash
$ Usage: generate_dm.py <input json file>
Examples:
- generate_dm.py tools_input.json
==> Generate all required files defined in tools_input.json file
```
The parameters/keys used in tools_input.json file are mostly self-explanatory but few parameters are required a bit more details.
| Key | Description |
|-----|-------------|
| vendor_list | This option should have the same name of the vendor directory names |
| dm_json_files | This should contain the list of json file path, where each file contains the definition of DM objects/parameters |
| vendor_prefix | The prefix used by vendor for vendor extension in DM objects/parameters |
| output.acs | Currently the tool support two variants of xml definitions of DM objects/parameters |
| | hdm: This variant of xml is compatible with Nokia HDM ACS |
| | default: This contains the generic definition which has the capability to define more descriptive DM objects/parameters |
| output.file_format | xls: An excel file listing the supported and unsupported DM objects/parameters |
> Note: To add more description about the vendor extended DM objects/parameters, it is required to add the definition of the required/related DM objects/parameters in a json file (The json structure should follow same format as given in [tr181.json](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/dmtree/json/tr181.json)), The same json file need to be defined in dm_json_files list.
The input json file should be defined as follow:
```bash
{
"manufacturer": "iopsys",
"protocol": "DEVICE_PROTOCOL_DSLFTR069v1",
"manufacturer_oui": "002207",
"product_class": "DG400PRIME",
"model_name": "DG400PRIME-A",
"software_version": "1.2.3.4",
"vendor_list": [
"iopsys",
"openwrt",
"test"
],
"dm_json_files": [
"../dmtree/json/tr181.json",
"../dmtree/json/tr104.json"
]
"vendor_prefix": "X_IOPSYS_EU_",
"plugins": [
{
"repo": "https://dev.iopsys.eu/iopsys/mydatamodel.git",
"proto": "git",
"version": "tag/hash/branch",
"dm_files": [
"src/datamodel.c",
"src/additional_datamodel.c"
]
},
{
"repo": "https://dev.iopsys.eu/iopsys/mybbfplugin.git",
"proto": "git",
"version": "tag/hash/branch",
"dm_files": [
"dm.c"
]
},
{
"repo": "https://dev.iopsys.eu/iopsys/mydatamodeljson.git",
"proto": "git",
"version": "tag/hash/branch",
"dm_files": [
"src/plugin/datamodel.json"
]
},
{
"repo": "/home/iopsys/sdk/mypackage/",
"proto": "local",
"dm_files": [
"src/datamodel.c",
"additional_datamodel.c"
]
},
{
"repo": "/src/feeds/mypackage/",
"proto": "local",
"dm_files": [
"datamodel.c",
"src/datamodel.json"
]
}
],
"output": {
"acs": [
"hdm",
"default"
],
"file_format": [
"xml",
"xls"
],
"output_dir": "./out",
"output_file_prefix": "datamodel"
}
}
```
> Note1: For the local repository, you must use an absolute path as repo option.
> Note2: If proto is not defined in the json config file, then git is used by default as proto option.
- For more examples of tools input json file, you can see this link: [tools_input.json](https://dev.iopsys.eu/iopsys/bbf/-/tree/devel/tools/tools_input.json)

77
docs/guide/vendor.md Normal file
View file

@ -0,0 +1,77 @@
# BBFDM Vendor
`bbfdm` library can be used to **Extend** the Data Model with new objects/parameters, to **Overwrite** existing objects/parameters with new ones and **Exclude** some objects/parameters from Data Model tree.
## How to add new vendor
### 1. Create a vendor folder
Create a new folder under **'dmtree/vendor/'** which contains all files related to the vendor
### 2. Fill Extend, Overwrite and Exclude tables with objects/parameters
Create the first vendor C file which contains new **Extend**, **Overwrite** and **Exclude** tables of objects/parameters.
#### Extend and Overwrite table
The Extend and Overwrite tables contain entries of **DM_MAP_OBJ** structure.
The **DM_MAP_OBJ** structure contains three arguments:
| Argument | Description |
| ---------------- | ------------------------------------------------------------------------------------------------------------- |
| `parentobj` | A string of the parent object name. Example “Device.IP.Diagnostics.”, “Device.DeviceInfo”, “Device.WiFi.Radio.” |
| `nextobject` | Pointer to a **DMOBJ** array which contains a list of the child objects |
| `parameter` | Pointer to a **DMLEAF** array which contains a list of the child parameters |
#### Exclude table
Each entry in the exclude table is a string which could be a path of object or parameter that need to be excluded from the tree
The following [link](https://dev.iopsys.eu/iopsys/bbf/-/blob/devel/dmtree/vendor/test/tr181/vendor.c) contains example of Extend, Overwrite and Exclude table.
### 3. Adding vendor and standard objects/Parameters
Implement the new vendor/standard objects and parameters as defined above in the first section.
Example: [Custom Vendor Object Dropbear](https://dev.iopsys.eu/iopsys/bbf/-/blob/devel/dmtree/vendor/test/tr181/x_test_com_dropbear.c)
### 4. link vendor tables to the main tree
To register the new vendor tables, you need to link them in the main three tables:
- **tVendorExtension**
- **tVendorExtensionOverwrite**
- **tVendorExtensionExclude**
These tables are defined in the file **'dmtree/vendor/vendor.c'**.
Example: [Link vendor tables to the main tree](https://dev.iopsys.eu/iopsys/bbf/-/blob/devel/dmtree/vendor/vendor.c)
### 5. Enable vendor
To enable the new vendor
- Define **BBF_VENDOR_EXTENSION** macro
- Add the new vendor in the list **BBF_VENDOR_LIST** macro
- Define the vendor prefix using **BBF_VENDOR_PREFIX** macro
Example of Config Options:
```bash
BBF_VENDOR_EXTENSION=y
BBF_VENDOR_LIST="iopsys,test"
BBF_VENDOR_PREFIX="X_TEST_COM_"
```
> Note1: The `libbbfdm` vendor list can support multi-vendor with comma seperated.
> Note2: If multi vendors are supported and there is a object/parameter that is implmented by multi customers in different way, the implemented object/parameter of the first vendor name in the **BBF_VENDOR_LIST** will be considered.
> Note3: Overwrite and Exclude are only considered in `dmtree/vendor/<vendor>/`
- The directory **'dmtree/vendor/test/'** contains an example of **test** vendor implementation

90
docs/mkdocs.yml Executable file
View file

@ -0,0 +1,90 @@
site_name: Documentation Instructions
site_url: https://docs.iopsys.se/portal2/bbf/
edit_uri: "https://dev.iopsys.eu/docs/portal2/bbf"
site_description: IOWRT Technical Documentation
site_author: IOPSYS
docs_dir: '.'
site_dir: 'site'
theme:
name: material
include_sidebar: true
highlightjs: true
hljs_languages:
- yaml
- python
language: en
font:
text: Roboto
code: Roboto Mono
logo: iopsys-white.svg
icon:
logo: icon.png
repo: fontawesome/brands/gitlab
extra:
social:
- icon: fontawesome/brands/github-alt
link: https://github.com/squidfunk
features:
- toc.autohide
- navigation.tabs
- navigation.tabs.sticky
- navigation.top
- navigation.tracking
- navigation.expand
palette:
# Primary color used for header, sidebar and links, default: indigo
primary: black
# Accent color for highlighting user interaction, default: indigo
accent: deep orange
extra_css:
- css/extra.css
- https://unpkg.com/mermaid@8.5.1/dist/mermaid.css
- https://cdn.jsdelivr.net/gh/fancyapps/fancybox@3.5.7/dist/jquery.fancybox.min.css
extra_javascript:
- https://unpkg.com/mermaid/dist/mermaid.min.js
- https://cdn.jsdelivr.net/npm/jquery@3.5.1/dist/jquery.min.js
- https://cdn.jsdelivr.net/gh/fancyapps/fancybox@3.5.7/dist/jquery.fancybox.min.js
markdown_extensions:
- meta
- admonition
- pymdownx.arithmatex
- pymdownx.betterem:
smart_enable: all
- pymdownx.caret
- pymdownx.critic
- pymdownx.details
- pymdownx.emoji:
emoji_index: !!python/name:materialx.emoji.twemoji
emoji_generator: !!python/name:materialx.emoji.to_svg
- pymdownx.inlinehilite
- pymdownx.magiclink
- pymdownx.mark
- pymdownx.smartsymbols
- pymdownx.tasklist:
custom_checkbox: true
- pymdownx.tilde
- pymdownx.superfences:
# make exceptions to highlighting of code:
custom_fences:
- name: mermaid
class: mermaid
format: !!python/name:mermaid2.fence_mermaid
- fontawesome_markdown
plugins:
- search:
lang:
- en
separator: '[\s\-\.]+'
- awesome-pages:
collapse_single_pages: true
- mermaid2
- section-index

10
docs/preview.sh Executable file
View file

@ -0,0 +1,10 @@
#!/usr/bin/env bash
# Copy README.md as index.md and change links
pip install -r requirements.txt
# Copy README.md as index.md and change links
sed -r -e 's![\.\/]*docs[\/]*!./!g' ../README.md > index.md
# Start mkdocs local server
mkdocs serve -f mkdocs.yml

7
docs/requirements.txt Executable file
View file

@ -0,0 +1,7 @@
mkdocs
mkdocs-material
mkdocs-awesome-pages-plugin
mkdocs-section-index
fontawesome_markdown
mkdocs-print-site-plugin
mkdocs-mermaid2-plugin

View file

@ -1,9 +1,5 @@
# dmtest Schema
```
https://dev.iopsys.eu/iopsys/uspd/-/blob/devel/docs/api/dmtest.json
```
| Custom Properties | Additional Properties |
| ----------------- | --------------------- |
| Forbidden | Forbidden |