Besides changing one or another configuration through make menuconfig, there is a way to customize the resulting target filesystem.

Create a new directory called extra in the top OpenADK directory. Put there a tree of directories and files that will be copied directly over the target filesystem (root_*) after everything is build, but before the firmware images or archives are created.

You can also point to another directory via:

 $ make extra=/foo/bar

You can start with the example configuration files from root_*. The extra directory will never be deleted by any clean target to avoid loss of customized configuration data.

Another option is to configure a post-build action. This is available in Global settings. It must point to a script relative to the root of your openadk working copy. It will be invoked as part of the -imageinstall step with $ADK_TOPDIR as first argument. You can use it e.g. to modify the root_* filesystem before bundling it.

Busybox is very configurable, and you may want to customize it. You can just configure it via Package selection, Base System, Busybox Configuration. The menu based busybox configuration is mostly integrated into OpenADK. There are some options, which are not available and not supported. If you need to, you can change the defaults in package/busybox/config and regenerate your OpenADK configuration.

A change in the busybox configuration will rebuild the busybox package. If you choose another implementation of f.e. tar, which is provided by default from busybox, tar in busybox will be deactivated and the package will be automatically rebuilt, so that your resulting firmware images or archives will only contain a single tar program. Obviously just the one you have selected.

Just like BusyBox uClibc-ng offering a lot of configuration options. They allow you to select various functionalities depending on your needs and limitations. OpenADK chooses automatically the best configuration regarding resulting code size, standard conformance, portability and GNU libc compatibility.

If you still have the requirements to change the default, regenerate a new uClibc-ng config from the existing one:

 $ tar xvf dl/uClibc-ng-x.y.z.tar.xz
 $ cd uClibc-ng-x.y.z
 $ cp ../target/<arch>/uclibc-ng.config .config
 $ make menuconfig

Make all required changes. Then copy the newly created uClibc-ng configuration back and rebuild your targetsystem, including the toolchain components:

 $ cp .config ../target/<arch>/uclibc-ng.config
 $ cd .. && make cleandir && make

There are no customization options for GNU libc or musl available.

The Linux kernel can be configured in the following manners by choosing the desired "Kernel configuration" option in the OpenADK configuration menu:

Choosing the first option, OpenADK uses a combination of Linux miniconfig feature and user defined features to generate a valid Linux configuration for your target. Some features and drivers are not selectable via make menuconfig, either because your choosen target system does not have support for it or the option is not implemented, yet. OpenADK uses some kind of abstraction layer between the real full featured and complicated Linux kernel configuration and you. It is not perfect and does include a lot of manual work in target/linux/config, but it works in an acceptable way.

If you just want to view the Linux configuration, which is actually used for your target, you can execute following command:

 $ make kernelconfig

Any changes here will get lost and will not be used to generate a kernel for your target. If you want to change the existing kernel configuration you need to follow these steps.

The basic kernel configuration used for your choosen target is concatenated from following two files: target/linux/kernel.config and target/<arch>/kernel/<system>.

So if you would like to change any basic stuff, just edit the files and recreate your firmware via:

 $ make

OpenADK automatically recognizes any change and will rebuild the kernel.

The base kernel configuration for your target generated by OpenADK is normally just enough to bootup the system with support for your board, serial console, network card and boot medium. (like a hard disk, sd card or flash partition)

If you need to enable some new optional drivers or features, which are not available in make menuconfig, you need to dig in target/linux/config. There is the abstraction layer for the real kernel configuration.

The defconfig option will choose a kernel in-tree default configuration specific to your target architecture. You won’t be able to do further customization.

Choosing the external configuration option, the OpenADK menu will prompt for the location of a Linux .config file relative to the OpenADK root directory. You will be able to alter the configuration by make kernelconfig. But the changes will get lost unless you save your changes by executing

 $ make savekconfig

after completing the Linux kernel configuration dialog. Despite this is the most flexible way to configure the kernel, keep in mind that you are fully responsible to enable all kernel features needed to mount your filesystems and required by your applications.

There is no simple way to change anything for the toolchain. OpenADK chooses the best combination of the toolchain components to provide you with a working and recent system.

If you like to change the version of a component, add patches or like to change the configure options, you need to dig into the toolchain directory.

For example to change the version of gcc, you need to change toolchain/gcc/Makefile.inc. Be aware of the fact, that this is used for the package/gcc/Makefile and therefore for the gcc running on your target.

OpenADK supports running a cross-compiled toolchain on your target. You can even use OpenADK buildsystem on your target. There is a package collection called development, which does configure OpenADK to include all required software to use OpenADK on your target.

When you have a OpenADK configuration that you are satisfied with and you want to share it with others, put it under revision control or move on to a different OpenADK project.

You just need to copy your .config and extra directory to regenerate your firmware images on another system. The used config is, if not explicitely disabled, saved on the target in /etc/adkconfig.gz.

The OpenADK project recommends and encourages upstreaming to the official OpenADK version the packages and board support that are written by developers. However, it is sometimes not possible or desirable because some of these packages or board support are highly specific or proprietary.

In this case, OpenADK users are offered following choice using here own git repository.

Personalize your Git environment via:

 $ git config --global user.name "Waldemar Brodkorb"
 $ git config --global user.email wbx@openadk.org

Get the latest version of OpenADK via anonymous git:

 $ git clone --bare git://openadk.org/git/openadk myadk.git

Use git-daemon to make the repository public to your developers. After that clone your new shared project repository:

 $ git clone git+ssh://myserver.com/git/myadk.git
 $ cd myadk

Configure OpenADK remote git repository:

 $ git remote add openadk git://openadk.org/git/openadk

Now you can either start with the latest version or use some older version:

 $ git checkout -b stable_1_0 $sha1

You can find $sha1 via git log. $sha1 is the hash after the keyword “commit”.

Now build a firmware image for your target and test it. Fix bugs in the build environment or add new stuff. You can use the “extra” directory to add local unpackaged binaries and/or configuration files to overwrite packaged stuff.

Check your uncommitted changes:

 $ git status
 $ git diff --cached
 $ git diff

Commit your git-added changes:

 $ git commit

Or just commit all changes:

 $ git commit -a

It is a good style to make a lot of small atomic commits.

Push your changes back to your git repository. For new local branches:

 $ git push origin stable_1_0

Or in regulary usage via:

 $ git push

You can generate patches from all your changes against the remote master:

 $ git format-patch -s origin

Send all relevant patches to OpenADK author via eMail.

Update your master with changes from OpenADK:

 $ git checkout master
 $ git pull openadk master

If you want you can merge all changes to your branch:

 $ git checkout stable_1_0
 $ git merge master

Or just cherry-pick some of the commits:

 $ git cherry-pick $sha1

Tag your tested stable branch:

 $ git tag -a stable_1.0

Push your tag to your repository:

 $ git push origin stable_1.0

Checkout your tag and build your firmware:

 $ git clone git+ssh://myserver.com/git/myadk.git mytag
 $ cd mytag
 $ git checkout stable_1.0

Deleting branches remotely:

 $ git branch -r
 $ git push origin :branchname

Deleting branches locally:

 $ git branch
 $ git branch -D branchname

OpenADK tries to detect what part of the system should be rebuilt when the system configuration is changed through make menuconfig. In some cases it automatically rebuilds packages, but sometimes just a warning is printed to the terminal, that a rebuild is necessary to make the changes an effect. If strange things are happening, the autodetection might have not worked correctly, then you should consider to rebuild everything. If you are following development you should always do a full rebuild after fetching updates via git pull. It is not always required, but if anything fails, you are on your own. Use following to do a full rebuild without refetching distfiles:

 $ make cleandir && make

In OpenADK you can rebuild a single package with:

 $ make package=<pkgname> clean package

It will automatically remove all files added to the staging target directory target_*. If you just want to restart compilation process, after making some fixes in build_*/w-<pkgname>-<pkgversion>/, just do:

 $ make package=<pkgname> package

If you are happy with your changes to the package sources, you can automatically generate a patch, which will be saved in package/<pkgname>/patches and automatically applied on the next clean rebuild:

 $ make package=<pkgname> update-patches

The newly created patches will be opened in $EDITOR, so you can add some comments to the top of the file, before the diff.

If you intend to do an offline build and just want to download all sources that you previously selected in the configurator then issue:

 $ make download

You can now disconnect or copy the content of your dl directory to the build-host.

OpenADK also honors some environment variables, when they are passed to make. The most useful and common ones are:

An example that creates a configuration file for Raspberry PI with all software packages enabled, but not included in the resulting firmware image:

 $ make ADK_APPLIANCE=new ADK_TARGET_ARCH=arm ADK_TARGET_SYSTEM=raspberry-pi ADK_TARGET_LIBC=musl allmodconfig

This is often used in the development process of a target system, to verify that all packages are compilable.

You may want to compile, for your target, your own programs or other software that are not packaged in OpenADK. In order to do this you can use the toolchain that was generated by OpenADK.

The toolchain generated by OpenADK is located by default in toolchain_<gnu_host_name>/. The simplest way to use it is to add toolchain_<gnu_host_name>/usr/bin/ to your PATH environment variable and then to use <arch>-<vendor>-linux-<libcsuffix>-gcc, <arch>-<vendor>-linux-<libcsuffix>-objdump, etc.

It is possible to relocate the toolchain, you just need to put target_<arch>_<libc>_<libcsuffix> into the same directory as toolchain_<gnu_host_name>/.

ccache is a compiler cache. It stores the object files resulting from each compilation process, and is able to skip future compilation of the same source file (with same compiler and same arguments) by using the pre-existing object files. When doing almost identical builds from scratch a number of times, it can nicely speed up the build process.

ccache support is integrated in OpenADK. You just have to enable Use ccache to speedup recompilation in Globale settings. This will automatically build ccache and use it for every target compilation.

The cache is located in $HOME/.ccache. It is stored outside of OpenADK directory so that it can be shared by separate OpenADK builds. If you want to get rid of the cache, simply remove this directory.

The various tarballs that are downloaded by OpenADK are all stored in ADK_DL_DIR, which by default is the dl directory. If you want to keep a complete version of OpenaDK which is known to be working with the associated tarballs, you can make a copy of this directory. This will allow you to regenerate the toolchain and the target filesystem with exactly the same versions.

If you maintain several OpenADK trees, it might be better to have a shared download location. This can be achieved by pointing the DL_DIR environment variable to a directory. If this is set, then the value of ADK_DL_DIR in the OpenADK configuration is overridden. The following line should be added to <~/.bashrc>.

 $ export DL_DIR=<shared download location>

The download location can also be set in the .config file, with the ADK_DL_DIR option. Unlike most options in the .config file, this value is overridden by the DL_DIR environment variable.

Running make package=<package> package builds and installs that particular package. Be aware of the fact, that no build dependencies are resolved using this method!

For packages relying on the OpenADK infrastructure, there are numerous special make targets that can be called independently like this:

 $ make package=<package> <target>

The package build targets are (in the order they are executed):

Additionally, there are some other useful make targets:

The normal operation of OpenADK is to download a tarball, extract it, configure, compile and install the software component found inside this tarball. The source code is extracted in build_<system>_<arch>_<libc>/w-<package>-<version>, which is a temporary directory: whenever make clean or one of the other clean targets are used, this directory is entirely removed, and recreated at the next make invocation.

This behavior is well-suited when OpenADK is used mainly as an integration tool, to build and integrate all the components of an embedded Linux system. However, if one uses OpenADK during the development of certain components of the system, this behavior is not very convenient: one would instead like to make a small change to the source code of one package, and be able to quickly rebuild the system with OpenADK.

Following workflow might help to integrate your own changes, while developing a new package or board support.

Make changes directly in build_<system>_<arch>_<libc>/w-<package>-<version> and recompile the package with:

 $ make package=<package> package

When you are happy with the change, generate a patch:

 $ make package=<package> update-patches

For the linux kernel just change the code in +build_<system>_<arch>_<libc>/linux, remove the .config and call make again:

 $ rm build_<system>_<arch>_<libc>/linux/.config
 $ make

There is no update-patches target for the kernel, you need to extract the kernel source from your download dir, make a copy of the source tree, add your changes and create a patch manually:

 $ tar xvf dl/linux-x.y.z.tar.xz
 $ cp -a linux-x.y.z linux-x.y.z.orig
 $ diff -Nur linux-x.y.z.orig linux-x.y.z > target/linux/patches/x.y.z/mykernel.patch
 $ make cleankernel
 $ make

The same method can be used for toolchain components and must be used for busybox, because it contains patches, which are not generated via make update-patches.

Config.in files contain entries for almost anything configurable in OpenADK. Mostly all Config.in files for packages are autogenerated and should not be manually edited. The following rules apply for the top level Config.in, for the files in target/config and target/linux/config.

An entry has the following pattern:

config ADK_TARGET_FOO
        bool "foo"
        select BR2_PACKAGE_LIBBAR
        depends on ADK_PACKAGE_LIBBAZ
        default n
        help
          This is a comment that explains what foo is.

          http://foo.org/foo/

The Config.in files are the input for the configuration tool used in OpenADK, which is an enhanced version of Kconfig. For further details about the Kconfig language, refer to http://kernel.org/doc/Documentation/kbuild/kconfig-language.txt.

ifeq ($(ADK_PACKAGE_LIBFOO_WITH_PYTHON),y)
CONFIGURE_ARGS+=        --with-python-support
else
CONFIGURE_ARGS+=        --without-python-support
endif

The documentation uses the asciidoc format.

For further details about the asciidoc syntax, refer to http://www.methods.co.nz/asciidoc/userguide.html.

First of all, create a directory and Makefile under the package directory for your software, for example libfoo:

 $ make newpackage PKG=libfoo VER=0.1

This will create a sample Makefile for you, with a lot of comments and hints. It describes how the package should be downloaded, configured, built, installed, etc.

Depending on the package type, the Makefile must be written in a different way, using two different infrastructures:

Dependencies on target and toolchain options

Some packages depend on certain options of the toolchain: mainly the choice of C library and C++ support. Some packages can only be built on certain target architectures or for specific target systems.

These dependencies have to be expressed in the Makefile. The given values are space separated and can be negated with ! as a prefix.

Further formatting details: see the writing rules.

By packages with specific build systems we mean all the packages whose build system is not the standard one, speak autotools. This typically includes packages whose build system is based on hand-written Makefiles or shell scripts.

01: # This file is part of the OpenADK project. OpenADK is copyrighted
02: # material, please see the LICENCE file in the top-level directory.
03:
04: include $(ADK_TOPDIR)/rules.mk
05:
06: PKG_NAME:=          libfoo
07: PKG_VERSION:=       1.0
08: PKG_RELEASE:=       1
09: PKG_HASH:=          62333167b79afb0b25a843513288c67b59547acf653e8fbe62ee64e71ebd1587
10: PKG_DESCR:=         foo library
11: PKG_SECTION:=       libs
12: PKG_BUILDDEP:=      libressl
13: PKG_DEPENDS:=       libressl
14: PKG_URL:=           http://www.libfoo.org/
15: PKG_SITES:=         http://download.libfoo.org/
16:
17: include $(ADK_TOPDIR)/mk/package.mk
18:
19: $(eval $(call PKG_template,LIBFOO,libfoo,${PKG_VERSION}-${PKG_RELEASE},${PKG_DEPENDS},${PKG_DESCR},${PKG_SECTION}))
20:
21: CONFIG_STYLE:=              manual
22: BUILD_STYLE:=               manual
23: INSTALL_STYLE:=             manual
24:
25: do-configure:
26:     ${CP} ./files/config ${WRKBUILD}/.config
27:
28: do-build:
29:     ${MAKE} -C ${WRKBUILD} all
30:
31: do-install:
32:     ${INSTALL_DIR} ${IDIR_LIBFOO}/usr/lib
33:     ${CP} ${WRKBUILD}/libfoo.so* ${IDIR_LIBFOO}/usr/lib
34:
35: include ${ADK_TOPDIR}/mk/pkg-bottom.mk

The Makefile begins with line 4 with the inclusion of the top level rules.mk file. After that the Makefile starts on line 6 to 15 with metadata information: the name of the package (PKG_NAME), the version of the package (PKG_VERSION), the release number of the package (PKG_RELEASE), which is used in OpenADK to mark any package updates, the sha256 hash of the source archive (PKG_HASH), the short one line description for the package (PKG_DESCR), the package section for the menu configuration system (PKG_SECTION), the package buildtime dependencies (PKG_BUILDDEP), the package runtime dependencies (PKG_DEPENDS), the package homepage (PKG_URL) and finally the internet locations at which the tarball can be downloaded from (PKG_SITES). override the default via the DISTFILES variable. You can add more then one archive name in DISTFILES via space separated. If you have no source archive at all, just use the boolean variable NO_DISTFILES and set it to 1.

On line 17 the mk/package.mk file is included, which contains the PKG_template function, which is used in line 19.

On line 21 to 23 we define that the configuration step, the building and install steps are manually provided.

On line 25-26 we implement a manual configuration step of the libfoo package by copying a manually created config file into the build directory.

On line 28-29 we start the compilation process via make.

On line 31-33 we install the shared library into the package installation directory, which is used to create the resulting binary package or tar archive for the target.

On line 35 we include mk/pkg-bottom.mk, which includes common functions used by the package fetching and building process.

First, let’s see how to write a Makefile file for an autotools-based package, with an example:

01: # This file is part of the OpenADK project. OpenADK is copyrighted
02: # material, please see the LICENCE file in the top-level directory.
03:
04: include ${ADK_TOPDIR}/rules.mk
05:
06: PKG_NAME:=          libfoo
07: PKG_VERSION:=       1.0
08: PKG_RELEASE:=       1
09: PKG_HASH:=          62333167b79afb0b25a843513288c67b59547acf653e8fbe62ee64e71ebd1587
10: PKG_DESCR:=         foo library
11: PKG_SECTION:=       libs
12: PKG_BUILDDEP:=      curl
13: PKG_DEPENDS:=       libcurl
14: PKG_URL:=           http://www.libfoo.org/
15: PKG_SITES:=         http://downloads.libfoo.org/
16:
17: include ${ADK_TOPDIR}/mk/package.mk
18:
19: $(eval $(call PKG_template,LIBFOO,libfoo,${PKG_VERSION}-${PKG_RELEASE},${PKG_DEPENDS},${PKG_DESCR},${PKG_SECTION}))
20:
21: libfoo-install:
22:     ${INSTALL_DIR} ${IDIR_LIBFOO}/usr/lib
23:     ${CP} ${WRKINST}/usr/lib/libfoo.so* ${IDIR_LIBFOO}/usr/lib
24:
25: include ${ADK_TOPDIR}/mk/pkg-bottom.mk

The Makefile begins with line 4 with the inclusion of the top level rules.mk file. After that the Makefile starts on line 6 to 15 with metadata information: the name of the package (PKG_NAME), the version of the package (PKG_VERSION), the release number of the package (PKG_RELEASE), which is used in OpenADK to mark any package updates, the sha256 hash of the source archive (PKG_HASH), the short one line description for the package (PKG_DESCR), the package section for the menu configuration system (PKG_SECTION), the package buildtime dependencies (PKG_BUILDDEP), the package runtime dependencies (PKG_DEPENDS), the package homepage (PKG_URL) and finally the internet locations at which the tarball can be downloaded from (PKG_SITES). override the default via the DISTFILES variable. You can add more then one archive name in DISTFILES via space separated. If you have no source archive at all, just use the boolean variable NO_DISTFILES and set it to 1.

On line 17 the mk/package.mk file is included, which contains the PKG_template function, which is used in line 19.

On line 21-23 we install the shared library into the package installation directory, which is used to create the resulting binary package or tar archive for the target.

On line 25 we include mk/pkg-bottom.mk, which includes common functions used by the package fetching and building process.

With the autotools infrastructure, all the steps required to build and install the packages are already defined, and they generally work well for most autotools-based packages. However, when required, it is still possible to customize what is done in any particular step. By adding a post-operation hook (after extract, patch, configure, build or install). See Section 7.3.5, “Hooks available in the various build steps” for details.

First, let’s see how to write a Makefile for an host only package, required by another target package to build, with an example:

01: # This file is part of the OpenADK project. OpenADK is copyrighted
02: # material, please see the LICENCE file in the top-level directory.
03:
04: include $(ADK_TOPDIR)/rules.mk
05:
06: PKG_NAME:=              hostfoo
07: PKG_VERSION:=           1.0
08: PKG_RELEASE:=           1
09: PKG_HASH:=              62333167b79afb0b25a843513288c67b59547acf653e8fbe62ee64e71ebd1587
10: PKG_DESCR:=             hostfoo utility
11: PKG_SECTION:=           misc
12: PKG_URL:=               http://www.foo.org/
13: PKG_SITES:=             http://download.foo.org/
14:
15: PKG_CFLINE_HOSTFOO:=    depends on ADK_HOST_ONLY
16:
17: include $(ADK_TOPDIR)/mk/host.mk
18: include $(ADK_TOPDIR)/mk/package.mk
19:
20: $(eval $(call HOST_template,HOSTFOO,hostfoo,$(PKG_VERSION)-${PKG_RELEASE}))
21:
22: HOST_STYLE:=            auto
23:
24: include ${ADK_TOPDIR}/mk/host-bottom.mk
25: include ${ADK_TOPDIR}/mk/pkg-bottom.mk

The differences to a target package is the inclusion of mk/host.mk in line 17 and mk/host-bottom.mk in line 24. Furthermore the HOST_template is called instead of the PKG_template. The last difference is the usage of PKG_CFLINE_HOSTFOO to mark the package as host only package.

Following mix between host and target package is possible, too:

01: # This file is part of the OpenADK project. OpenADK is copyrighted
02: # material, please see the LICENCE file in the top-level directory.
03:
04: include ${ADK_TOPDIR}/rules.mk
05:
06: PKG_NAME:=          foo
07: PKG_VERSION:=       1.0
08: PKG_RELEASE:=       1
09: PKG_HASH:=          62333167b79afb0b25a843513288c67b59547acf653e8fbe62ee64e71ebd1587
10: PKG_DESCR:=         foo tool
11: PKG_SECTION:=       lang
12: PKG_BUILDDEP:=      foo-host
13: PKG_URL:=           http://www.foo.org/
14: PKG_SITES:=         http://download.foo.org/
15:
16: include ${ADK_TOPDIR}/mk/host.mk
17: include ${ADK_TOPDIR}/mk/package.mk
18:
19: $(eval $(call HOST_template,FOO,foo,${PKG_VERSION}-${PKG_RELEASE}))
20: $(eval $(call PKG_template,FOO,foo,${PKG_VERSION}-${PKG_RELEASE},${PKG_DEPENDS},${PKG_DESCR},${PKG_SECTION}))
21:
22: HOST_STYLE:=        auto
23:
24: foo-install:
25:     ${INSTALL_DIR} ${IDIR_FOO}/usr/bin
26:     ${INSTALL_BIN} ${WRKINST}/usr/bin/foo ${IDIR_FOO}/usr/bin
27:
28: include ${ADK_TOPDIR}/mk/host-bottom.mk
29: include ${ADK_TOPDIR}/mk/pkg-bottom.mk

If you need to rebuild a mixed package, you can do:

 $ make package=<package> hostclean hostpackage clean package

If your host package have some dependencies, use following:

 HOST_BUILDDEP:=libbaz-host bar-host

The infrastructure allow packages to specify hooks. These define further actions to perform after existing steps. Most hooks aren’t really useful for manual packages, since the Makefile already has full control over the actions performed in each step of the package construction.

The following hook targets are available:

For example, to make some scripts executable after extraction, add following to your Makefile:

post-extract:
        chmod a+x $(WRKBUILD)/build/make/*.sh
        chmod a+x $(WRKBUILD)/build/make/*.pl

As you can see, adding a software package to OpenADK is simply a matter of writing a Makefile using an existing template and modifying it according to the compilation process required by the package.

If you package software that might be useful for other people, don’t forget to send a patch to the OpenADK developer (see Section 9.1, “Submitting patches”)!

The list of variables that can be set in a Makefile to give metadata information is:

The recommended way to define these variables is to use the following syntax:

PKG_VERSION:=           2.11

Or for lines longer than 80 characters use:

PKG_DEPENDS:=           foo bar baz
PKG_DEPENDS+=           muh maeh

The variables that define what should be performed at the different steps of the configure, build and install process.

The variables to add or override preprocessor, compiler and linker flags:

Patches are released under the same license as the software that is modified.

A message explaining what the patch does, and why it is needed, should be added in the header commentary of the patch. At the end, the patch should look like:

add C++ support test

--- configure.ac.orig
+++ configure.ac
@@ -40,2 +40,12 @@

AC_PROG_MAKE_SET
+
+AC_CACHE_CHECK([whether the C++ compiler works],
+               [rw_cv_prog_cxx_works],
+               [AC_LANG_PUSH([C++])
+                AC_LINK_IFELSE([AC_LANG_PROGRAM([], [])],
+                               [rw_cv_prog_cxx_works=yes],
+                               [rw_cv_prog_cxx_works=no])
+                AC_LANG_POP([C++])])
+
+AM_CONDITIONAL([CXX_WORKS], [test "x$rw_cv_prog_cxx_works" = "xyes"])

When integrating a patch of which you are not the author, you have to add a few things in the header of the patch itself.

Depending on whether the patch has been obtained from the project repository itself, or from somewhere on the web, add one of the following tags:

Backported from: <some commit id>

or

Fetched from: <some url>

It is also sensible to add a few words about any changes to the patch that may have been necessary.

OpenADK tries to avoid any patches to the source code. If a patch could not be avoided, it should be tried to make the patch of a good quality to get it upstream. OpenADK tries to report any found issues and try to send in any upstream compatible patches.

If you want to present the whole patch set in a separate mail, add --cover-letter to the git format-patch command (see man git-format-patch for further information). This will generate a template for an introduction e-mail to your patch series.

A cover letter may be useful to introduce the changes you propose in the following cases:

Example for loopback device configuration:

auto lo
iface lo inet loopback

Example for an ethernet network card:

auto eth0
iface eth0 inet static
  address 192.168.1.1
  netmask 255.255.255.0
  broadcast +
  gateway 192.168.1.254

The DNS resolver must be manually configured in /etc/resolv.conf. The plus for the broadcast value, will calculate the correct broadcast address for the network.

Example for an ethernet network card:

auto eth0
iface eth0 inet dhcp

Example for a network bridge with two ethernet network interfaces and an ip address:

auto br0
iface br0 inet static
        address 192.168.99.1
        netmask 255.255.255.0
        broadcast +
        bridge-ports eth0 eth1

Just a bridge without an ip address:

auto br0
iface br0 inet manual
         bridge-ports eth0 eth1

You need to install either Busybox brctl applet or the bridge-utils package. The required kernel modules will be automatically selected.

Example configuration of a network interface with VLAN ID 8 without any ip configuration:

auto eth0.8
iface eth0.8 inet manual

You need to install Busybox vconfig applet. The required kernel modules will be automatically selected.

Typical DSL configuration:

auto ppp0
iface ppp0 inet ppp
        use-template pppoe
        provider isp
        ppp-mtu 1412
        ppp-username foo
        ppp-password bar
        ppp-device eth1

The provider can be used as argument for "pon" and "poff" commands. You need to install the ppp and ppp-mod-pppoe package. The required kernel modules will be automatically selected.

Example wireless client configuration, secured with WPA2:

auto wlan0
iface wlan0 inet dhcp
        wireless-ssid myap
        wireless-channel 11
        wireless-mode sta
        wireless-security wpa2
        wireless-passphrase xxxxxx

You need to install iw and wpa_supplicant packages. For older wireless drivers you need to install wireless-tools instead of iw and use the following variable to choose the right tools:

wireless-extension 1

To configure an access point use following example:

auto wlan0
iface wlan0 inet static
        address 192.168.40.10
        netmask 255.255.255.0
        broadcast +
        wireless-ssid myap
        wireless-channel 8
        wireless-mode ap
        wireless-security wpa2
        wireless-passphrase xxxxxx

You need to install hostapd and iw/wireless-tools packages.

If you have a HSO UMTS modem, you can use following to configure internet access:

auto hso0
iface hso0 inet manual
        pin 1234
        apn your.apn

For example a configuration on a Linksys AG241 router with integrated DSL modem, you can configure two ATM devices to distinguish between Internet and IPTV traffic:

auto eth0.1
iface eth0.1 inet manual

auto eth0.8
iface eth0.8 inet manual

auto nas0
iface nas0 inet manual

auto nas1
iface nas1 inet manual
        atm-vpi 1
        atm-vci 34

auto br0
iface br0 inet manual
        bridge-ports eth0.1 nas0

auto br1
iface br1 inet manual
        bridge-ports eth0.8 nas1

More network setups can be implemented on request.