Skip to content

Latest commit

 

History

History
172 lines (119 loc) · 5.07 KB

developers-guide.md

File metadata and controls

172 lines (119 loc) · 5.07 KB
Raw

Developer's Guide

Please note, by default the root account is disabled in Infix NETCONF builds. Meaning, the only way to access the system is with the admin account, which is created based on credentials found in the VPD area -- for Qemu devices this is emulated using qemu_fw_cfg.

For developers this can be quite frustrating to be blocked from logging in to debug the system. So we recommend enabling the root account in the Buildroot make menuconfig system.

make menuconfig
     -> System configuration
        -> [*]Enable root login with password

Cloning

When pre-built releases are not enough, for instance when you want to add or modify some Open Source components, you can clone the Infix tree to your PC:

$ mkdir ~/Projects; cd ~/Projects
$ git clone https://github.com/kernelkit/infix.git
$ cd infix/
$ git submodule update --init

Please see the Contributing section, below, for details on how to fork and clone when contributing to Infix.

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.

$ ...
$ git submodule update --init --recursive
                              ~~~~~~~~~~~

Other caveats should be documented in the customer specific trees.

Building

Buildroot is almost stand-alone, it needs a few locally installed tools to bootstrap itself. The most common ones are usually part of the base install of the OS, but specific ones for building need the following. The instructions here are for Debian/Ubuntu based systems (YMMV):

$ sudo apt install bc binutils build-essential bzip2 cpio \
                   diffutils file findutils git gzip      \
                   libncurses-dev libssl-dev perl patch   \
                   python3 rsync sed tar unzip wget       \
                   autopoint bison flex

For testing, a few more tools and services are required on your system:

$ sudo apt install jq graphviz qemu-system-x86 qemu-system-arm \
				   ethtool gdb-multiarch tcpdump tshark

For details, see the Getting Started and System Requirements sections of the excellent manual.

To build an Infix image; select the target and then make:

make x86_64_defconfig
make

Online help is available:

make help

To see available defconfigs for supported targets, use:

make list-defconfigs

Development

When changing a package, locally kept sources, or when using local.mk, you only want to rebuild the parts you have modified:

make foo-rebuild

or

make foo-reconfigure

or, when nothing seems to bite:

make foo-dirclean foo-rebuild

As shown here, you can combine multiple build targets and steps in one go, like this:

make foo-rebuild bar-rebuild all run

This rebuilds (and installs) foo and bar, the all target calls on Buildroot to finalize the target filesystem and generate the images. The final run argument is explained below.

Testing

Manual testing can be done using Qemu by calling make run, see also Infix in Virtual Environments.

The Infix automated test suite is built around Qemu and Qeneth, see:

Contributing

Infix is built from many parts, when contributing you need to set up your own fork, create a local branch for your change, push to your fork, and then use GitHub to create a Pull Reqeuest.

For this to work as painlessly as possible:

  1. Fork Infix to your own user or organization1
  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.

$ cd ~/Projects
$ git clone https://github.com/YOUR_USER_NAME/infix.git
$ cd infix/
$ git submodule update --init

Note: when updating/synchronizing with upstream Infix changes you may have to synchronize your forks as well. GitHub have a Sync fork button in the GUI for your fork for this purpose.

Footnotes

  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. ↩