mirror of
https://github.com/kernelkit/infix.git
synced 2026-07-30 04:33:00 +02:00
Drop Hybrid Mode from default builds, update documentation
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This commit is contained in:
committed by
Tobias Waldekranz
parent
2c4b67cbbc
commit
bc048f6313
@@ -1,2 +1 @@
|
||||
set COLORTERM=yes
|
||||
runparts /cfg/start.d
|
||||
|
||||
+1
-1
@@ -153,7 +153,7 @@ Automating start/stop at boot/reboot is documented in the next section.
|
||||
### Hybrid Mode
|
||||
|
||||
Since container setup and configuration is not modeled in YANG yet, we
|
||||
use the Infix *Hybrid mode*, also described in the README.
|
||||
use the Infix *Hybrid mode*, described in [Infix Variants](variant.md).
|
||||
|
||||
To start containers in *Hybrid Mode*, provided the images have been
|
||||
downloaded with `podman pull docker://troglobit/buildroot:latest` and
|
||||
|
||||
+32
-1
@@ -14,6 +14,26 @@ $ cd infix/
|
||||
$ git submodule update --init
|
||||
```
|
||||
|
||||
### Customer Builds
|
||||
|
||||
Customer builds add product specific device trees, more OSS packages,
|
||||
e.g., Frr and podman, and sometimes integrates proprietary software.
|
||||
What's *important to remember*, however, is that they are all made by
|
||||
setting up Infix as a GIT submodule, similar to how Infix set up a GIT
|
||||
submodule for Buildroot.
|
||||
|
||||
So, in addition to using the customer's specific defconfig(s), one must
|
||||
also make sure to update *all submodules*, otherwise you will likely end
|
||||
up with a broken build.
|
||||
|
||||
```bash
|
||||
$ ...
|
||||
$ git submodule update --init --recursive
|
||||
~~~~~~~~~~~
|
||||
```
|
||||
|
||||
Other caveats should be documented in the customer specific trees.
|
||||
|
||||
|
||||
Building
|
||||
--------
|
||||
@@ -59,10 +79,15 @@ and then use GitHub to create a *Pull Reqeuest*.
|
||||
|
||||
For this to work as painlessly as possible:
|
||||
|
||||
1. Fork Infix to your own user
|
||||
1. Fork Infix to your own user or organization[^1]
|
||||
2. Fork all the Infix submodules, e.g., `buildroot` to your own user
|
||||
or organization as well
|
||||
3. Clone your fork of Infix to your laptop/workstation
|
||||
|
||||
If you use a GitHub organization you get the added benefit of having
|
||||
local peer reviews of changes before making a pull request to the
|
||||
upstream Infix repository.
|
||||
|
||||
```bash
|
||||
$ cd ~/Projects
|
||||
$ git clone https://github.com/YOUR_USER_NAME/infix.git
|
||||
@@ -74,5 +99,11 @@ $ git submodule update --init
|
||||
> may have to synchronize your forks as well. GitHub have a `Sync fork`
|
||||
> button in the GUI for your fork for this purpose.
|
||||
|
||||
[^1]: Organizations should make sure to lock the `main` (or `master`)
|
||||
branch of their clones to ensure members do not accidentally merge
|
||||
changes there. Keeping these branches in sync with upstream Infix
|
||||
is highly recommended as a baseline and reference. For integration
|
||||
of local changes another company-specific branch can be used instead.
|
||||
|
||||
[1]: https://buildroot.org/downloads/manual/manual.html
|
||||
[2]: https://github.com/wkz/qeneth
|
||||
|
||||
@@ -63,6 +63,15 @@ To work around that we use the [run-parts(8)][] feature of the system,
|
||||
available in some customer specific images. The system runs any user
|
||||
scripts in `/cfg/start.d` before leaving runlevel S (bootstrap).
|
||||
|
||||
> **Note:** a vanilla Infix build does not support Hybrid Mode out of
|
||||
> the box. You can enable it, and build your own images by adding the
|
||||
> following line to `board/common/rootfs/etc/finit.conf`:
|
||||
>
|
||||
> runparts /cfg/start.d
|
||||
>
|
||||
> See the [Developer's Guide](developers-guide.md) for a build HowTo.
|
||||
|
||||
|
||||
### Starting OSPF
|
||||
|
||||
For example, the following starts OSPF:
|
||||
|
||||
Reference in New Issue
Block a user