1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
|
<!--#set var="title" value="Development" -->
<!--#set var="pagetitle" value="Development" -->
<!--#include file="includes/header.html" -->
<h2>Source Repositories</h2>
<dl>
<dt><a href="http://git.os.pehjota.net/pkg/">Packages in Git</a></dt>
<dd>Most source packages are maintained in Git repositories. To assist in the maintenance of a package, coordinate with its maintainer(s) and the <a href="http://www.pehjota.net/contact.html">system administrator</a>.</dd>
<dt><a href="http://git.os.pehjota.net/notes/">Notes, specifications, and policies</a></dt>
<dd>Specifications and policies are maintained in Git repositories.</dd>
<dt><a href="http://git.os.pehjota.net/www/">Web site</a></dt>
<dd>These Web pages are maintained in a Git repository.</dd>
</dl>
<h2>Specifications</h2>
<dl>
<dt><a href="http://specs.os.pehjota.net/source-package-format-1.0.html">Source Package Format 1.0</a></dt>
<dd>The format in which source packages are developed.</dd>
<dt><a href="http://specs.os.pehjota.net/architecture-string.html">Architecture String Syntax</a></dt>
<dd>The meaning of the architecture string for binary architectures and application platforms.</dd>
<dt><a href="http://specs.os.pehjota.net/multiarch.html">Multiarch</a> (to be written)</dt>
<dd>The ability to install and use on a system packages built for multiple architectures.</dd>
<!--
<dt><a href="http://specs.os.pehjota.net/service-run-control.html">Service Run Control</a> (to be written)</dt>
<dd>A modular system for ordering the starting and stopping of system services according to inter-service dependencies.</dd>
-->
</dl>
<h2>Policies</h2>
<p>Packages must adhere to a number of policies for distribution as part of this operating system.</p>
<dl>
<dt><a href="http://policies.os.pehjota.net/packaging.html">Packaging Policy</a> (to be written)</dt>
<dd>Requirements for package naming, splitting, and data.</dd>
<dt><a href="http://policies.os.pehjota.net/filesystem.html">Filesystem Hierarchy Policy</a> (to be written)</dt>
<dd>The structure of the files and directories in the system.</dd>
<dt><a href="http://policies.os.pehjota.net/software.html">Software Inclusion Policy</a> (to be written)</dt>
<dd>Legal and technical requirements to protect user freedom and to ensure that all included software can be legally distributed and effectively supported.</dd>
</dl>
<h2>Development Environment</h2>
<p>All packages are cross-built using a toolchain consisting of kernel headers, GNU Binutils, GCC, and a standard C/C++ library. The cortexa8-linux-eglibc port, for example, is <a href="http://git.os.pehjota.net/notes/free-embedded-os.git/tree/temporary-bootstrap-builder-setup-cortexa8.txt">currently built</a> using Linux-libre 3.2.7, GMP 5.0.2, MPFR 3.1.0, MPC 0.9, Binutils 2.22, GCC 4.6.2, and EGLIBC 2.15.</p>
<p>This operating system currently supports the following programming languages: C (ISO/IEC 9899 as <a href="http://gcc.gnu.org/onlinedocs/gcc/Standards.html">implemented by GCC</a>), C++ (ISO/IEC 14882 as <a href="http://gcc.gnu.org/onlinedocs/gcc/Standards.html">implemented by GCC</a>), UNIX shell command language (POSIX.1-2008 XCU), and microprocessor assembly languages (with syntax and directives as implemented in GNU as). Support for more languages (e.g. Perl and Python) will come as their respective interpreters and compilers are packaged; this may take time as these programs usually have many build-time and run-time dependencies and some of these programs cannot easily be cross-built.</p>
<h2>Remaining Tasks</h2>
<p>The following is an overview of development projects that need to be done before the operating system can be considered ready for production use.</p>
<h3>Boot Sequencing</h3>
<p>Currently, service init scripts are provided by the monolithic <code>initscripts</code> binary package. These init scripts are executed in the lexicographic order of the symbolic links matching <code>/etc/rc.d/S*</code> that target them. The names of these symbolic links are currently hardcoded in <a href="http://git.os.pehjota.net/pkg/basefiles.git/tree/build?id=0ae24516#n43">the <code>build</code> makefile</a> of the <code>basefiles</code> source package. This monolithic packaging and hardcoding of link names is a temporary and poor technical solution that doesn't scale with the number and selection of services that can be installed on a system. Init scripts should instead be provided by the packages that provide the relevant system services. The order in which init scripts are executed should be determined by dynamic boot sequencing based on inter-service dependency metadata.</p>
<p>This boot sequencing can be done when the system boots or after a new system service is installed. For reference, NetBSD <a href="http://www.netbsd.org/docs/guide/en/chap-rc.html#chap-rc-rcorder">uses a program called "rcorder"</a> to determine a boot sequence at boot time. Many GNU/Linux distributions follow (to some degree) the Linux Standard Base (LSB) specification, which defines <a href="http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html">"Comment Conventions" for dependency metadata</a> and <a href="http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html">a method for installing sequentially-named symbolic links</a>. Conforming implementations perform boot sequencing at the time of service installation. Because boot sequencing at boot time can slow down system booting, it is better to perform boot sequencing at install time.</p>
<p>Thus, generally speaking, the solution to be adopted in this system is to make packages that provide system services also include the necessary init scripts (installed in <code>/etc/init.d</code>), to include inter-service dependency metadata in init scripts, and to use a tool at the time of service package installation to generate sequentially-named symoblic links in <code>/etc/rc.d</code>.</p>
<p>An obvious boot sequencing tool is <a href="http://svn.savannah.nongnu.org/viewvc/insserv/trunk/?root=sysvinit">"insserv"</a> maintained by Werner Fink and used by Debian and openSUSE. However, this C program (in compliance with the LSB) assumes the use of runlevels. This operating system uses the init daemon of BusyBox, which <a href="http://git.busybox.net/busybox/tree/init/init.c?id=3da46c81#n1221">doesn't support runlevels</a>. Therefore, we'll need to either modify insserv to work without runlevels or write our own tool for installing symbolic links to init scripts.</p>
<p>Additionally, we need to decide how completely we'll conform, if at all, with the LSB in this area.</p>
<h3>Multiarch</h3>
<p>Multiarch refers to the ability to install and use packages built for non-native architectures. It is currently being <a href="http://wiki.debian.org/Multiarch">documented and implemented</a> in Debian and Ubuntu. Multiarch is useful for this distribution because it makes cross compiling easy (see "Package Cross Building Tool" and "Multiarch Cross Toolchain Packages" below).</p>
<p>Simply speaking, there are six <a href="https://wiki.ubuntu.com/MultiarchSpec#Design">aspects of a multiarch implementation</a>:</p>
<ul>
<li>
<h4>Filesystem Hierarchy</h4>
<p>To accomodate simultaneous installation of shared libraries built for different architectures, library paths are suffixed with a directory name that identifies a particular architecture. For this distribution, that directory name will be the name of the binary architecture; for example, library paths for the <code>cortexa8-linux-eglibc</code> architecture will be <code>/lib/cortexa8-linux-eglibc</code> and <code>/usr/lib/cortexa8-linux-eglibc</code>.</p>
<p>The toolchain (especially the dynamic linker) needs to be configured to use these library paths.</p>
</li>
<li>
<h4>A <code>Multi-Arch</code> Control Field</h4>
<p>A <code>Multi-Arch</code> control field specifies how a package can satisfy dependencies of other packages. A value of <code>same</code> means that a package can only satisfy dependencies of packages built for the architecture for which it was built. This is useful for shared libraries, which can only be dynamically linked against binary objects built for the same architecture. A value of <code>foreign</code> means that a package can satisfy dependencies of packages built for any architecture. This is useful for utility programs, which can be used by software built for any architecture.</p>
<p>The package manager (opkg in our case) and package building tools (specifically oh-checkbuilddeps of opkhelper) must be able to understand and use this field in resolving package dependencies.</p>
</li>
<li>
<h4>Architecture Specification in Package Relationships</h4>
<p>Control fields like <code>Depends</code> are extended to support an architecture specification of either <code>any</code> or <code>same</code>, allowing a package to specify whether or not it needs a package of the same architecture. The dependent package has a <code>Multi-Arch</code> field with value <code>allowed</code>.</p>
<p>The package manager and package building tools must be able to understand and use this architecture syntax in relationship fields.</p>
</li>
<li>
<h4>Handling of Packages with <code>Architecture: all</code></h4>
<p>Dependence on packages installable and usable on any architecture (especially considering opkg's ability to install packages of multiple architectures) must be researched.</p>
</li>
<li>
<h4>Non-Library Files in Library Packages</h4>
<p>Library packages provide files outside of system library paths, such as configuration and package documentation files. A solution must be designed to allow a package built for one architecture to be co-installable with the same package built for a different architecture (or to determine if they are co-installable at all).</p>
</li>
<li>
<h4>Ability to Install Packages Built for Non-Native Architectures</h4>
<p>The package manager must be able to install packages built for multiple architectures (the whole point of multiarch). Fortunately for us, opkg already handles this. The <code>arch</code> option in <code>opkg.conf</code> <a href="http://wiki.openwrt.org/doc/techref/opkg#adjust.architectures">allows the user to specify architectures</a> for which packages can be installed.</p>
</li>
</ul>
<p>In summary, there is much design work to be done, opkg and opkhelper must be modified to support multiarch, and certain packages will need to be built to handle multiarch library paths. Of course Debian is a great reference implementation, but there still remains much original work to be done.</p>
<h3>Installation Bootstrap Tool</h3>
<p>A tool similar to <a href="http://anonscm.debian.org/gitweb/?p=d-i/debootstrap.git;a=tree">debootstrap</a> of Debian needs to be written to bootstrap the installation of a basic system. It can be used for building packages (see "Package Cross Building Tool" below) or installing the operating system on hardware targets.</p>
<p>Basically, the tool would fetch from the package archive the index of packages, determine which packages need to be installed, download each package, and unpack each package. Since the package manager may not be available, the tool must handle dependency resolution and package unpacking on its own.</p>
<p>We can't use debootstrap, since the formats of our binary packages and package archives differ slightly from those of Debian. But we can model our tool after debootstrap or even just fork debootstrap.</p>
<h3>Package Cross Building Tool</h3>
<h3>Multiarch Cross Toolchain Packages</h3>
<!--#include file="includes/footer.html" -->
|
