Subversion Repositories tendra.SVN

<?xml version="1.0" standalone="no"?>

<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"

"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">

<!--

  $Id$

-->

<book>

  <bookinfo>

    <title>Validation of TenDRA Capability to Implement a Set of Commands for

      the Linux Operating System</title>

    <corpauthor>The TenDRA Project</corpauthor>

    <authorgroup>

      <author>

        <firstname>Fran&ccedil;ois</firstname>

        <surname>de Ferri&egrave;re</surname>

        <affiliation>

          <orgname>Open Software Foundation Research Institute</orgname>

        </affiliation>

      </author>

      <author>

        <firstname>Fred</firstname>

        <surname>Roy</surname>

        <affiliation>

          <orgname>Open Software Foundation Research Institute</orgname>

        </affiliation>

      </author>

      <editor>

        <firstname>Jeroen</firstname>

        <surname>Ruigrok van der Werven</surname>

      </editor>

    </authorgroup>

    <abstract>

      <para>This report describes work done under contract to the Defence

        Research Agency (DRA) of the U.K.  It is an extension of an earlier

        contract to assess the capability of the DRA TenDRA technology to

        express a fully portable operating system implementation.</para>

    </abstract>

  </bookinfo>

  <chapter>

    <title>Executive Summary</title>

      <para>During a first phase of the project the main goal was to examine

        the extent to which the TenDRA technology could be used to compile a

        complete operating sytem. This experiment was carried out on the

        Unixware operating system on an Intel 486 platform. Although Unix

        sources are known to be compiler dependent, it was found that most of

        the code could be compiled with no, or minor, modifications.  Details

        of the results can be found in a

        <biblioref linkend="Ferri&egrave;re95-2">report</biblioref>.

      </para>

      <para>The goal of this second phase of the project was

        to study the feasibility of producing Unix commands in architecture

        neutral (ANDF) format which could be readily ported to different

        hardware platforms running the same operating system.  The target

        system chosen for this second phase was Linux, which was available on

        both the Intel and DEC Alpha platforms (although the latter was

        incomplete at the beginning of the project).</para>

      <para>The experiment carried out during this second phase was very

        successful.  A significant amount of complex code was converted to the

        architecture neutral ANDF format, and the portability of this code was

        demonstrated. However, due to time constraints, the number of commands

        ported to both platforms was more limited than had been hoped.  The

        project also provided some interesting lessons about the strengths and

        limitations of the ANDF/TenDRA technology and about API issues.This is

        the final report on work undertaken on the Linux operating system on

        the Intel/i386 and Digital/Alpha platforms.</para>

  </chapter>

  <chapter>

    <title>2. Objectives and Description</title>

    <sect1>

      <title>2.1 Objectives</title>

      <para>In previous work, we performed validation, performance and

        robustness testing of the TenDRA technology to ensure its capability

        to implement and fully bootstrap a UNIX-like operating system. We also

        provided an assessment of the capability of TenDRA technology to

        express a fully portable operating system implementation. This work

        was very successful, and the results are reported in a

        <biblioref linkend="Ferri&egrave;re95-2">summary report</biblioref>.

      </para>

      <para>However, though we originally planned to conduct this first

        experiment on two different architectures, an Intel/486 and a

        Sun/Sparc platforms running UnixWare, it was completed only for the

        Intel/486 platform.  After discussions with DRA, it was then decided

        to focus the second part of the project on the Unix commands, and to

        switch from the UnixWare to the Linux operating system. The

        motivations for a revised plan were:</para>

      <itemizedlist>

        <listitem>OSF is developing a Linux server for the Intel/486 and

          PowerPC platforms, and we would like to deliver the set of

          associated commands in ANDF format. In the event, native Linux

          commands for PowerPC became available in the meantime.</listitem>

        <listitem>Repeating on the Sparc platform the work already done on the

          i486 platform would bring little added-value, while requiring a

          significant amount of work.  The major benefit of the work on a

          second platform would be to demonstrate that a set of commands along

          with its API can be defined in ANDF format and then installed on two

          different platforms.</listitem>

      </itemizedlist>

      <para>Thus, the objective of the second part of the project is the

        production in ANDF format of Linux commands, and their installation on

        two platforms. This will demonstrate the ability of the TenDRA

        technology to produce a set of architecture neutral commands and, at

        completion of the project, will provide a set of freely distributable

        commands in ANDF format.</para>

      <para>The project, which lasted 9 months, started on July 1995, and was

        finished at the end of March 1996.</para>

      <para>This report summarizes all the work done under the contract for

        this second part of the project.</para>

    </sect1>

    <sect1>

      <title>2.2 General description</title>

      <para>The commands, one part of a Unix system, are based on some

        standard APIs, XPG3 for example, plus some extensions, which together

        form the interface shared with the libraries against which they are

        built. The commands should not have any assembly code, unlike the

        other parts of a Unix system.</para>

      <para>As for other software OSF already ported to ANDF, the port of the

        Linux commands is done in three steps:</para>

      <itemizedlist>

        <listitem>The NAT-NAT step, which consists in rebuilding the commands

          with the native compilation chain, to ensure that they can be

          regenerated from their source files.</listitem>

        <listitem>The DRA-NAT step, for which the TenDRA technology is used as

          a replacement of the native compilation chain to build the commands,

          using the native system header files, as for a classical compilation

          chain. This part involves dealing with discrepancies between the

          native and the TenDRA code generators.</listitem>

        <listitem>The DRA-DRA step, which will consist in using the TenDRA

          technology as a portability tool. The API shared by the commands and

          libraries is defined, and used to produce the commands in

          architecture independent ANDF code. This code will be installed and

          validated on the selected machines.</listitem>

      </itemizedlist>

      <para>We initially planned to conduct the experiment on the Intel/i386

        and IBM/PowerPc platforms, both running the Linux operating system.

        However, the Linux system for the IBM/PowerPC platform was still under

        development at the time we needed it, in December 1995. So we decided

        to replace it by a Digital/Alpha platform, the only other platform for

        which a Linux port was sufficiently advanced at that time.  However,

        it is a 64-bit platform, so this switch was more of a challenge,

        because of the fundamental change in data sizes. It provided

        additional tests of the TenDRA portability attributes.</para>

      <para><A NAME="90"></A></para>

    </sect1>

  </chapter>

  <chapter>

    <title>3. Description of Project phases</title>

    <para>In this section we specify the tasks which have been performed under

      this project.</para>

    <para>The set of commands which were ported to ANDF was split into two

      subsets:</para>

    <itemizedlist>

      <listitem>The <I>level 1</I> subset corresponds to the level achieved

        with UnixWare at the end of the first project (about 100 commands out

        of 600).  These commands conform to a standard interface (Posix or

        XPG) with some simple extensions. They do not use extensions which are

        difficult to port from one system to another.  This set includes about

        150 Linux commands.</listitem>

      <listitem>The <I>level 2</I> subset corresponds to the maximum which can

        be reasonably achieved for a given system. While we could expect about

        twice as many commands as for level 1, we only compiled about 75 more

        commands.</listitem>

    </itemizedlist>

    <sect1>

      <title>Phase 1: level 1 commands on Intel/i386</title>

      <para>The objective is to produce a ``level 1'' set of Linux commands in

        ANDF format for the Intel platform. This requires the production of

        the associated API, also in ANDF format (token library).</para>

      <para>The major tasks for this phase are:</para>

      <sect2>

        <title>T1. Linux installation.</title>

        <itemizedlist>

          <listitem>Install the Linux system.</listitem>

          <listitem>Install a compilation environment.</listitem>

          <listitem>Install the Linux source code.</listitem>

        </itemizedlist>

        <para><emphasis>Prerequisite:</emphasis> Linux system for

          Intel.</para>

        <para><emphasis>Delivery:</emphasis> System running.</para>

      </sect2>

      <sect2>

        <title>T2. TenDRA installation.</title>

        <itemizedlist>

          <listitem>Install the TenDRA technology for Linux.</listitem>

        </itemizedlist>

        <para><emphasis>Prerequisite:</emphasis>TenDRA technology &amp;

          T1.</para>

        <para><emphasis>Delivery:</emphasis> TenDRA installed.</para>

      </sect2>

      <sect2>

        <title>T3. Level 1 commands port.</title>

        <itemizedlist>

          <listitem>Define the level 1 set of Linux commands.</listitem>

          <listitem>Compile the level 1 commands in NAT-NAT mode.</listitem>

          <listitem>Compile the level 1 commands in DRA-NAT mode.</listitem>

        </itemizedlist>

        <para><emphasis>Prerequisite:</emphasis> Linux source code, T1 &amp;

          T2.</para>

        <para><emphasis>Delivery:</emphasis> Level 1 commands compiled with

          TenDRA in native mode.</para>

      </sect2>

      <sect2>

        <title>T4. Level 1 commands API definition.</title>

        <itemizedlist>

          <listitem>Define the non-explicit API used by this set of commands.

            Machine dependent code issues will be addressed

            specifically.</listitem>

        </itemizedlist>

        <para><emphasis>Prerequisite:</emphasis> Linux source code.</para>

        <para><emphasis>Delivery:</emphasis> Set of ANDF header files for this

          level 1 API.</para>

      </sect2>

      <sect2>

        <title>T5. ANDFization of Level 1 commands.</title>

        <itemizedlist>

          <listitem>Produce the level 1 commands with the TenDRA technology,

            using the ANDF definition of the API defined in the previous

            task.</listitem>

        </itemizedlist>

        <para><emphasis>Prerequisite</emphasis>: Linux source code, T2 &amp;

          T4.</para>

        <para><emphasis>Delivery</emphasis>: Level 1 commands in ANDF

          format.</para>

      </sect2>

      <sect2>

        <title>T6. Level 1 commands API installation.</title>

        <itemizedlist>

          <listitem>Build the token library for the level 1 commands

            API.</listitem>

        </itemizedlist>

        <para><emphasis>Prerequisite</emphasis>: T2 &amp; T4.</para>

        <para><emphasis>Delivery</emphasis>: Token library for this level 1

          API.</para>

      </sect2>

      <sect2>

        <title>T7. Level 1 commands installation and validation.</title>

        <itemizedlist>

          <listitem>Install the commands in ANDF format produced in task T5.

          </listitem>

          <listitem>Validate the commands using adhoc tests.</listitem>

          <listitem>Write a report that describes the results obtained and

            the problems encountered.</listitem>

        </itemizedlist>

        <para><emphasis>Prerequisite</emphasis>: T2, T5 &amp; T6.</para>

        <para><emphasis>Delivery</emphasis>: Report on level 1 commands on

          Intel.</para>

      </sect2>

    </sect1>

    <sect1>

      <title>Phase 2: level 1 commands on Digital/Alpha</title>

      <para>The objective is to validate that the commands produced during the

        first phase can be easily ported to the Alpha platform.</para>

      <para>The major tasks, during this phase, are:</para>

      <sect2>

        <title>T8. Linux installation.</title>

        <itemizedlist>

          <listitem>Install the Linux system.</listitem>

          <listitem>Install a compilation environment, including header files

            and libraries.</listitem>

        </itemizedlist>

        <para><emphasis>Prerequisite</emphasis>: Linux system for

          Alpha.</para>

        <para><emphasis>Delivery</emphasis>: System running.</para>

      </sect2>

      <sect2>

        <title>T9. TenDRA installation.</title>

        <itemizedlist>

          <listitem>Adapt the TenDRA technology for Linux on the

            Alpha.</listitem>

          <listitem>Install the TenDRA technology.</listitem>

        </itemizedlist>

        <para><emphasis>Prerequisite</emphasis>: TenDRA technology &amp;

          T8.</para>

        <para><emphasis>Delivery</emphasis>: TenDRA installed.</para>

      </sect2>

      <sect2>

        <title> T10. Level 1 commands API installation.</title>

        <itemizedlist>

          <listitem>Build the token library for the level 1 commands

            API.</listitem>

        </itemizedlist>

        <para><emphasis>Prerequisite</emphasis>: T4 &amp; T9.</para>

        <para><emphasis>Delivery</emphasis>: Token library for this level 1

          API.</para>

      </sect2>

      <sect2>

        <title> T11. Level 1 commands installation and validation.</title>

        <itemizedlist>

          <listitem>NAT-NAT and DRA-NAT check.</listitem>

          <listitem>Install the commands in ANDF format produced in task

            T5.</listitem>

          <listitem>Validate the commands using adhoc tests.</listitem>

          <listitem>Write a report that describes the results obtained and

            the problems encountered.</listitem>

        </itemizedlist>

        <para><emphasis>Prerequisite</emphasis>: T5, T9 &amp; T10.</para>

        <para><emphasis>Delivery</emphasis>: Report on level 1 commands on

          Alpha.</para>

      </sect2>

    </sect1>

    <sect1>

      <title>Phase 3: level 2 commands on Intel/i386 and Digital/Alpha</title>

      <para>The objective during this phase is to validate further the ANDF

        tools by trying to extend the ANDF commands to a broader set that will

        include some ``difficult'' cases.</para>

      <para>The major tasks are:</para>

      <sect2>

        <title>T12. Level 2 commands port.</title>

        <itemizedlist>

          <listitem>Define the level 2 set of Linux commands, by extension of

            the level 1 set.</listitem>

          <listitem>Compile the level 2 commands in NAT-NAT mode on

            Intel.</listitem>

          <listitem>Compile the level 2 commands in NAT-NAT mode on

            Alpha.</listitem>

          <listitem>Compile the level 2 commands in DRA-NAT mode on

            Intel.</listitem>

          <listitem>Compile the level 2 commands in DRA-NAT mode on

            Alpha.</listitem>

        </itemizedlist>

        <para><emphasis>Prerequisite</emphasis>: Linux source code, T1, T2, T8

          &amp; T9.</para>

        <para><emphasis>Delivery</emphasis>: Level 2 commands compiled with

          TenDRA in native mode.</para>

      </sect2>

      <sect2>

        <title>T13. Level 2 commands API definition.</title>

        <itemizedlist>

          <listitem>Extend the level 1 API to include the interfaces used by

            the level 2 commands.</listitem>

        </itemizedlist>

        <para><emphasis>Prerequisite</emphasis>: Linux source code &amp;

          T4.</para>

        <para><emphasis>Delivery</emphasis>: Set of ANDF header files for this

          level 2 API.</para>

      </sect2>

      <sect2>

        <title>T14. Level 2 commands ANDFization.</title>

        <itemizedlist>

          <listitem>Produce the level 2 commands with the TenDRA technology,

            using the ANDF definition of the API defined in the previous

            task.</listitem>

        </itemizedlist>

        <para><emphasis>Prerequisite</emphasis>: Linux source code, T2, T9

          &amp; T13.</para>

        <para><emphasis>Delivery</emphasis>: Level 2 commands in ANDF

          format.</para>

      </sect2>

      <sect2>

        <title>T15. Level 2 commands API installation.</title>

        <itemizedlist>

          <listitem>Build the token library for the level 2 commands API on

            Intel.</listitem>

          <listitem>Build the token library for the level 2 commands API on

            Alpha.</listitem>

        </itemizedlist>

        <para><emphasis>Prerequisite</emphasis>: T2, T9 &amp; T13.</para>

        <para><emphasis>Delivery</emphasis>: Token library for this level 2

          API.</para>

      </sect2>

      <sect2>

        <title>T16. Level 2 commands installation and validation.</title>

        <itemizedlist>

          <listitem>Install the commands in ANDF format produced in task T14

            on Intel.</listitem>

          <listitem>Install the commands in ANDF format produced in task T14

            on Alpha.</listitem>

          <listitem>Validate the commands using adhoc tests.</listitem>

          <listitem>Write an intermediate report and a final

            report.</listitem>

        </itemizedlist>

          <para><I>Prerequisite</I>: T2, T9, T14 &amp; T15.</para>

          <para><I>Delivery</I>: Intermediate report on level 2 commands, and

            final report.</para>

      </sect2>

    </sect1>

  </chapter>

  <chapter>

    <title>4. Project environment</title>

    <sect1>

      <title>4.1 LINUX operating system</title>

      <para>Linux is a free Unix-like operating system, first developed by

        Linus Torvalds on an Intel platform; ``official'' releases exist since

        October 1991.</para>

  <para>It has now been ported to Digital/Alpha and ports to other

  machines, including PowerPC andPowerMAC, are under way.</para>

  <sect2>

  <title>Linux on Intel/i386</title>

  <para><A NAME="10407">There are many distributions of Linux for the Intel

  platform; we installed the Slackware distribution, based on the Linux 1.1

  version.</A></para>

  <para><A NAME="10408">We downloaded it from the ftp site:<BR/></A><A

  HREF="ftp://sunsite.unc.edu/pub/Linux/distributions/slackware">sunsite.unc.edu:/pub/Linux/distributions/slackware</A></para>

  <para><A NAME="10536">The version we installed was Linux 1.1.59, available since

  October 1994. Since then, newer versions have been released, but we stuck to

  this version throughout the project since it worked well, and because all the

  packages it included were easily available in source form (see below).</A></para>

  </sect2>

  <sect2>

  <title>Source code for Linux commands used by the project</title>

  <para><A NAME="10411">We downloaded the source code of the Linux commands from

  the ftp site:<BR/></A><A

  HREF="ftp://sunsite.unc.edu/pub/Linux/distributions/slackware/source">sunsite.unc.edu:/pub/Linux/distributions/slackware/

  source</A>.</para>

  <para><A NAME="10397">This means that the versions of commands available on our

  development machine for Linux/i386 were matching the source code we used as base

  for the project, except in a few cases for which the source code had been

  revised.</A></para>

  </sect2>

  <sect2>

  <title>Linux on Digital/Alpha</title>

  <para><A NAME="1551">For the Alpha platform, Linux is available from the `BLADE'

  distribution, and more recently from the Red Hat distribution.</A></para>

  <para>A 32-bit version of Linux/Alpha was first released in

  January 1995; then a 64-bit version was available in November 1995, which

  included most of the capabilities provided by the Linux/Intel system. We

  downloaded the BLADE_0.3 release, consisting of more than thirty floppy images,

  from the ftp site:<BR/><A HREF="ftp://ftp.digital.com/pub/DEC/Linux-Alpha">ftp.digital.com:/pub/DEC/Linux-Alpha</A></para>

  <para>Since December 1995, another Linux/Alpha distribution has

  become available from the RedHat company; it is built from the same components,

  but newer versions, as the BLADE release.</para>

  <para>An interesting feature of the current Linux/Alpha ports, is

  that they provide rather extensive binary compatibility with Digital Unix. This

  compatibility has been used to cross-build on Digital Unix for Linux/Alpha, and

  also for a few features which were not available in the Linux/Alpha BLADE

  release.</para>

</sect2>

  </sect1>

  <sect1>

  <title>4.2 Hardware platforms and environment</title>

  <para>The Intel platform was an Intel/i486 PC machine, with

      most disk space available through NFS.</para>

  <para>The Digital/Alpha platform was built specifically for

  this project, around a <I>Digital AXPpci 33</I> motherboard. In fact, at the

  time we set-up the machine, the Linux/Alpha ports were only running on a few

  Alpha-based machines.</para>

  <para>A Linux kernel had to be rebuilt for this machine in order

  to add support for the 3COM Ethernet board we used, and for the NFS-client

  capability. Most disk space was thus available through an NFS file system,

  shared with the Intel platform.</para>

  </sect1>

  <sect1>

  <title>4.3 TenDRA technology</title>

  <para>We started the project on an Intel platform with a snapshot of the

    TenDRA technology from April 1995, which included support for the

    Linux/Intel platform. This snapshot was based on the ANDF 3.1

    specification.</para>

  <para>We switched to the November 1995 TenDRA snapshot, based on ANDF 4.0,

    when we setup the second platform, in order to use the tools for the

    Digital Unix/Alpha platform. Because of the high degree of compatibility

    between Digital Unix and Linux on Alpha, we could use the TenDRA

    technology on a DigitalUnix/Alpha platform to cross-build executables for

    the Linux/Alpha platform.</para>

  <para>The ANDF 4.0 intermediate file format is not upward compatible with

    the ANDF 3.1 one, which required that we rebuild the intermediate ANDF

    files for the Linux commands we had already built.</para>

  <para>ANDF 4.0 contains increased capability, though not required by this

    project, and forms the basis for the X/Open preliminary

    specification XANDF.</para>

</sect1>

</chapter>

  <chapter>

    <title>5. Descriptions and Results of Project phases</title>

  <para>In the next paragraphs, we describe the way we accomplished

  the various tasks of the project and we summarize their results.</para>

  <sect1>

    <title>5.1 Linux installation</title>

  <para>At the beginning of the project, we installed the Linux operating

    system release 1.1 on an Intel/i386 machine. In December 1995, after a few

    months of work on the Intel/i386 platform, we installed Linux on the

    second platform for the project, which is a Dec/Alpha. Linux was first

    released on this platform at the beginning of 1995.</para>

  <sect2>

  <title>Linux/i386 installation (including the source code for commands)</title>

  <para>A machine with Linux 1.1.59 from the Slackware

  distribution, including the native compilation chain and libraries from GNU, was

  setup for the project.</para>

  <para>The Linux system is available on several anonymous ftp

  sites. The one we used was at  sunsite.unc.edu, where a distribution of the

  sources and binaries of the Intel/Linux commands from Slackware was available

  under the /pub/Linux/distributions/slackware directory. Note that the current

  Slackware distribution at the time of writing of this report is based on Linux

  3.0.</para>

  <para>In the Slackware Linux distribution for Intel/ix86, the

      delivery of the source code for commands is split into a large number of

      <I>packages</I>. The contents of each source package must be compiled

      and installed individually. For example, the <I>awk</I> command,

      actually <I>gawk</I>, belongs to the <B>bin</B> package which contains

      56 commands, while the <I>bc</I> command belongs to the <B>bc</B>

      package which contains only this one command.  Consequently, we did not

      download the whole set of sources for the Linux commands, but selected a

      few packages containing the sources of the commands we intended to build

      first. We also had a look at the Caldera Linux source distribution, and

      it appeared to be organized in the same way.</para> <para>

      A Slackware Linux package for source code distribution is

      made of a compressed tar files (usually only one), optional patch

      file(s), and a shell script. The execution of this shell script installs

      the source files from the tar file(s), applies patches if necessary,

      optionally performs a self-configuration step, runs the makefile(s) for

      the compilation, and finally generates a binary package which holds the

      resulting executables. This procedure has been adapted to fit the

      NAT-NAT, DRA-NAT and DRA-DRA development steps on two platforms, as

      described in the section<A HREF="linux_re.htm#4846">Setting up the

      build environment</A>.</para>

  <para>Note that each package has a private version number. Thus

  packages can be maintained and released independently. Moreover, some packages

  (e.g. the <B>bin</B> package) are a collection of several `subpackages', each

  of which has its own version number.</para>

  </sect2>

  <sect2>

  <title>Linux/Alpha installation</title>

  <para>The Linux Operating System port to the Digital Alpha architecture

    started two years ago. The first user-installable distribution was

    available in January 95, from the `BLADE' distribution, and was a 32-bit

    version. Then came a 64-bit version which was made compatible with Digital

    Unix with respect to basic C language types:</para>

  <informaltable>

    <row>

      <entry>int:</entry>

      <entry>32-bit</entry>

    </row>

    <row>

      <entry>long:</entry>

      <entry>64-bit</entry>

    </row>

    <row>

      <entry>pointer:</entry>

      <entry>64-bit</entry>

    </row>

  </informaltable>

  <para>While it is still under development, Linux/Alpha is now robust and

    includes most of the capabilities provided by the Linux/Intel

    system.</para>

  <para>The BLADE distribution was the first available distribution for

    Linux/Alpha. For the project, we retrieved the November 95 BLADE_0.3

    release, based on the Linux 1.3 development kernel, at the following

    site:</para>

  <para><A HREF="ftp://ftp.digital.com/pub/DEC/Linux-Alpha">	ftp.digital.com:/pub/DEC/Linux-Alpha</A></para>

  <para>This release consists of more than thirty 3.5'' floppy images (not

    including X-Window). The source code for the commands is not a part of

    this distribution. Since then, several new versions for the boot firmware,

    kernel, compiler and libraries have been released, but, as we encountered

    minor problems only with BLADE_0.3, we did not upgrade our system.</para>

  <para>Since December 95, another distribution of Linux for Dec/Alpha is also

    available from the RedHat company; the current version is:</para>

  <para><A HREF="ftp://ftp.redhat.com/pub/redhat/redhat-2.1/axp">ftp.redhat.com:/pub/redhat/redhat-2.1/axp</A></para>

  <para>This distribution includes all the source packages for the components

    it is made from, along with some fixes and additions, in both binary and

    source forms. It is possible to unpack a RedHat Linux/Alpha 2.1 set while

    not running the RedHat Linux, but, as a proprietary packaging format is

    used, one should install the packaging tools (<I>rpm</I>) first.</para>

  <para>At the time we setup the machine, Linux/Alpha was operational only on

  a few variants of Digital Alpha-based systems. So, we selected an entry

  level and rather inexpensive board, the Digital AXPpci 33

  Alpha PC motherboard, around which we built a machine. Our Linux/Alpha system

  currently comprises the following:</para>

  <itemizedlist>

    <listitem>an 8-slot enclosure with 200W power supply and fan</listitem>

    <listitem>Digital AXPpci 33 motherboard, Windows NT (ARC) firmware, PS/2

      style keyboard interface, 233 Mhz Alpha processor</listitem>

    <listitem>2x16MB, 36-bit, 70ns SIMMs</listitem>

    <listitem>256 KB, 20ns cache [optional part]</listitem>

    <listitem>a Number 9 GXE VGA display adapter (ISA)</listitem>

    <listitem>a dumb VGA display</listitem>

    <listitem>a PS/2 style keyboard</listitem>

    <listitem>a 3.5''/1440K floppy disk drive</listitem>

    <listitem>a SCSI-2 hard disk (a DECpc 2.0GB disk from Digital)</listitem>

    <listitem>a 3COM Ethernet Link-II (aka 3c503) controller (ISA).</listitem>

  </itemizedlist>

  <para>We installed the BLADE_0.3 distribution on our machine, including the

    C compilation chain and libraries. In order to use the 3COM Ethernet

    board, we had to rebuild the kernel. We used almost all of the default

    kernel build parameters, except for the Ethernet adapter, for the settings

    for the `TGA graphics' support (switched to `no') and for the NFS-client

    feature (selected). Note that a kernel rebuild takes more than half an

    hour on our system.</para>

  <para>A very interesting feature of the current releases of

    Linux/Alpha is that they provide an almost perfect <B>binary compatibility

    with Digital Unix</B>. This was of great help to us, as will be described

    later.</para>

  <para>Among the various updates to the Linux/Alpha boot

    loader, kernel, C compiler and libraries, commands, ..., which have been

    made by the Linux-Alpha development teams, we have used only a

    few:</para>

  <itemizedlist>

    <listitem>upgrade of the <command>sed</command> command: some sed scripts

      used for modifying the system headers when building the APIs with TenDRA

      caused the original <command>sed</command> command to abort.</listitem>

    <listitem>upgrade of a few system headers, extracted from the azstarnet

      <filename>inc-and-libs-0.38.tar.gz</filename> file.</listitem>

  </itemizedlist>

  <para><A NAME="2048">These two updates were downloaded from the

    site</A></para>

  <para><A HREF="ftp://ftp.azstartnet.com/pub/linux/axp">

    ftp.azstartnet.com:/pub/linux/axp</A></para>

  <para><A NAME="6416">We encountered a few problems with the BLADE_0.3

    release on the AXPpci Alpha board:</A></para>

  <itemizedlist>

    <listitem>The floppy disk driver sometimes entered a time-out, as

      indicated by a console message.</listitem>

    <listitem>Some shell scripts failed until a #!/bin/sh line, or equivalent,

      was inserted. According to a member of the Linux/Alpha development team,

      it is caused by the kernel command loader, and was fixed in new kernel

      releases. We worked-around this problem by patching a number of shell

      script files included with various source packages we were building on

      Linux/Alpha: we realized too late that it would have been preferable to

      upgrade the kernel.</listitem>

    <listitem>Linux/Alpha failed to mount an NFS file system served by a HP-UX

      release 8 machine. Fortunately, this problem disappeared when using a

      server running Solaris or HP-UX release 9: we had to move our

      development tree to such a host.</listitem>

    <listitem>As mentioned above, the sets of source files were shared through

      NFS between a Linux/Intel, a Digital Unix and a Linux/Alpha platform.

      Occasionally, Linux/Alpha lost access to a file that had been updated

      recently by another NFS client: the error message `<I>Stale NFS file

      handle</I>' was displayed.  Unmounting/remounting the NFS file system

      usually cured such problems.</listitem>

    <listitem>During kernel rebuilds, the compilation of at least one file

      failed because of lack of memory: in the makefiles for kernel rebuild,

      the gcc compiler is called with the `-pipe' option, which speeds up the

      build but is not safe when compiling large source files. We wrote a

      small shell script which redoes a compilation without the `-pipe'

      option. (This problem was fixed by a subsequent kernel release:

      <I>tcpip.c</I> was split into several parts...)</listitem>

  </itemizedlist>

</sect2>

  </sect1>

  <sect1>

  <title>5.2 TenDRA installation</title>

  <para>We first installed the TenDRA technology on the Linux/i386

  platform, from the April 1995 snapshot. Later, we installed the November 1995

  release, the first to include support for the Dec/Alpha machine, in order to

  start work on the Linux/Alpha platform. However, because this snapshot was not

  upward compatible with the previous TenDRA release, we also had to install it on

  the Linux/i386 platform. We did not upgrade to the February 1996 snapshot,

  though it is compatible with the previous one. We only used it in a few cases

  when we had a bug in a command and wanted to make sure that it was not due to a

  problem already fixed in TenDRA.</para>

  <sect2>

  <title>TenDRA installation on Intel/i386</title>

  <para>The TenDRA snapshot from April 1995, based on TDF 3.1,

  included support for the Linux/i386 platform. So, the installation on our

  machine was straightforward. We only had to recompile the tcc driver, and to

  modify some environment and startup files to fine tune the level of checking.</para>

  <para>When we started to work on the second platform, we had to

  install the November 1995 snapshot of the TenDRA technology (see below). This

  was DRA's first snapshot based on TDF 4.0, and it included significant changes

  to the installation procedure. We had some difficulties to install this

  snapshot, due to a few bugs in the new installation procedures, but once

  installed the technology appeared to work well.</para>

  <para><A NAME="2200"></A></para>

  </sect2>

  <sect2>

  <title>TenDRA installation on Dec/Alpha</title>

  <para><A NAME="5003">The TenDRA snapshot from November 1995 was the first

  snapshot with support for the Dec/Alpha platform, but was not upward compatible

  with the one installed on the Intel platform (TenDRA 4.0 versus TenDRA 3.1). So,

  the TenDRA snapshot from November 1995 was installed on both the Intel/i386 and

  the Dec/Alpha platforms.</A></para>

  <para><A NAME="2174">DRA provide support for the DigitalUnix/Alpha platform, not

  for the Linux/Alpha one. However, we benefited from the compatibility between

  Digital Unix and Linux to solve this problem.We made three different

  installations of the TenDRA technology for Alpha, among which the 2nd was fully

  operational for Linux/Alpha:</A></para>

  <para><A NAME="2151"></A></para>

  <itemizedlist>

  <listitem>First installation on native Digital Unix/alpha. 

  <A NAME="2152"></A></listitem>

  <listitem>Second installation, still on Digital Unix, but for cross-development for

  Linux/Alpha (termed <I>lin_alpha_cross</I>). 

  <A NAME="2153"></A></listitem>

  <listitem>Third installation on Linux/Alpha (termed <I>lin_alpha</I>). 

  </listitem></itemizedlist>

  <para><A NAME="2154">The first installation was straightforward and worked very

  well. The main purpose was to ensure that the TenDRA technology worked correctly

  on Dec/Alpha.</A></para>

  <para><A NAME="2279">For the second installation, we created a new target

  platform termed `lin_alpha_cross'. Most of the `lin_alpha_cross' files are

  shared with Digital Unix, using symbolic links to directories or files, since

  only a few files differ between the two targets. The main purpose of these

  changes was to use Linux/Alpha system header files when compiling, instead of

  the Digital Unix system header files, and Linux/Alpha libraries and startup

  files when link-editing. For example, we changed three files inside the <I>&lt;target_platform&gt;/private/env</I>

  directory named <I>default</I>, <I>system</I> and <I>tcc_diag</I>. For the

  same reason, we created a specific `lin_alpha_cross' subdirectory in lib/system

  to hold some replacement system header files when cross-compiling with the <I>-Ysystem</I>

  option (i.e. in DRA-NAT mode). The target dependent directories and files used

  when (cross-)building APIs for Linux/Alpha, e.g. located under the <I>src/apis/libs</I>

  directory, were also made specific.</A></para>

  <para><A NAME="2291">Using this installation, we could cross-compile and

  cross-link on Digital Unix for Linux, without any problem. The binary

  compatibility between Linux/Alpha and Digital Unix was thus a key factor of

  success.</A></para>

  <para><A NAME="2156">The third TenDRA installation for Linux/Alpha was readily

  derived from the previous one. We benefited again from the binary compatibility

  with Digital Unix: we ran the TenDRA compilation chain, built for Digital Unix,

  on top of Linux/Alpha, without the necessity to port it or recompile it.

  However, to do so, we had to copy and install the shared library tools of

  Digital Unix on Linux/Alpha because TenDRA uses shared libraries, for which

  there is currently no support in Linux/Alpha. The Digital Unix shared libraries

  mechanism works fine under Linux! This trick could have be avoided if we had

  re-linked the TenDRA tools under Digital Unix using its statically-linked

  libraries.</A></para>

  <para><A NAME="2157">In order to use the Linux/Alpha native assembler and

  link-editor instead of those from Digital Unix, we wrote a front-end shell

  script to the TenDRA installer (trans). This shell script calls the actual trans

  tool with an option to output a source assembly file instead of the `binary

  assembly' files used by the Digital Unix as1 tool. Similarly, we wrote a

  front-end shell script which emulates the call made by tcc to as1 by a call to

  the Linux as tool. We give below the changes to the settings in <lin_alpha>/private/env/default

  for the third installation:</A></para>

  <para><A NAME="2158"></A></para>

  <literallayout>+TRANS	``/..../linux/1.3.45/alpha/private/bin/trans.sh''

  +AS1	``/..../linux/1.3.45/alpha/private/bin/as1.sh''

  +AS	``/usr/bin/as -nocpp'' # seems unused

  +LD	``/usr/bin/ld -G8 -O1''

  </literallayout>

  <para><A NAME="2162">However, despite these modifications, the port of the TenDRA

  installer to Linux/Alpha could not be completed. In some cases, the TenDRA

  installer appeared to generate assembly instructions that are not recognized by

  the Linux/Alpha assembler. For example, the following lines could not be

  assembled properly by Linux/Alpha:</A></para>

  <para><A NAME="2163"></A></para>

  <literallayout>.extern __ctype_ 8

  	Error: Rest of line ignored. First ignored character is `8'

   stq $fp, 8($sp)

  	Warning: Illegal operands

   bis $17,$17,$fp

  	Warning: Illegal operands

   .frame $fp, 360, $26, 0

  	Error: bad absolute expression; zero assumed

  </literallayout>

  <para><A NAME="2164">We now understand it is not surprising that we were unable

  to use the TenDRA installer for Digital Unix/Alpha on Linux/Alpha. ANDF

  installer output needs to be tailored for different target operating systems

  according to the assembler and/or link editor interfaces supported by the target

  operating system. In our case we attempted to use the assembler interface, and

  the errors and warnings above are examples where this interface differs between

  Digital Unix/Alpha and Linux/Alpha. Debugger support and even some details of

  the procedure calling conventions may also need to be taken into account when

  tailoring an ANDF installer to a different operating system.</A></para>

  <para>Since we had already set up a cross-development TenDRA

  environment for Linux/Alpha, hosted by Digital Unix, we continued to use it and

  discontinued use of the `lin_alpha' installation. We actually installed TenDRA

  on an NFS file server (used by the Linux/ i386, the Digital Unix and the

  Linux/Alpha platforms).</para>

</sect2>

</sect1>

<sect1>

  <title>5.3 Build environment with TenDRA</title>

  <sect2>

  <title>Definition of the set of Linux commands</title>

  <para><A NAME="2647">The definition of the set of commands has not been done once

  for all. It has been done on the Intel/i386 platform, during the first part of

  the project, in two steps, level1 and level2, as described in </A><A

  HREF="linux_re.htm#90">Description of Project phases</A>. Each step has been

  performed as an incremental process. Each time new commands were selected, a

  whole cycle of API definition (<A HREF="linux_re.htm#2743">&#167;  5.4</A>),

  command ANDFization (<A HREF="linux_re.htm#2745">&#167;  5.5</A>), API

  installation (<A HREF="linux_re.htm#6139">&#167;  5.6</A>) and command

  installation and validation (<A HREF="linux_re.htm#1788">&#167;  5.7</A>) was

  performed.</para>

  <para><A NAME="2632">During the first phase of the project, a number of commands

  have been compiled in DRA-DRA mode on the Unixware platform (see </A><A

  HREF="linux_re.htm#6567">[2]</A>). We started by locating these commands in the

  packages from the Slackware Linux source distribution for Intel/ix86. Since

  these commands were among the simplest ones to ANDFize on Unixware, they were

  good candidates to start with. Provided that a full binary installation was made

  on our Linux/i386 platform, a command could be located in a package by searching

  for its name in the list of packages under the<I> /var/adm/packages</I>

  directory. This directory contains one text file per installed package, which

  records the names of the commands it contains (actually the relative

  installation path from / is provided for each command). When the name of the

  package which holds a command has been found, we just had to connect to the ftp

  site, find the directory of the same name in the Slackware source distribution,

  and download the files under this directory.</para>

  <para><A NAME="2495">Among the 103 Unixware commands ANDfized during the previous

  phase of this project, we found 59 commands with similar name in Linux,

  scattered among 11 packages: <I>bc, bin, bsdgames, diff, find, grep, gzip,

  sh_utils, txtutils </I>and <I>util</I>. Moreover, these packages also contained

  some additional commands which appeared to be good candidates for easy

  ANDFization. However, we excluded a few of them which were compiled but not

  delivered in the binary package, or which seemed too dependent on the target

  platform (e.g. the

  <I>fdformat</I> command which formats floppy disks). We also selected four

  additional packages, <I>tar, cpio, xlock</I> and <I>xgames</I>, in order to

  complete the <I>level 1</I> set of commands.</A></para>

  <para><A NAME="2572">The definition of the <I>level 2</I> set of commands was

  more difficult than for <I>level 1</I>, because we had to reject a number of

  commands, for various reasons discussed below.</A></para>

  <para><A NAME="11235">First, we tried to include in the <I>level 2</I> set of

  commands more commands from X11, as we successfully experimented the ANDFization

  of a few of them for<I> level 1</I>. However it appeared that this was not so

  easy: the sources for these commands had not been packaged by Slackware, but

  were provided inside a huge collection of sources named <I>Xfree86</I> (from

  the Xfree86 Project, Inc.), itself derived from the X Consortium X11R6 code. An

  attempt to perform the first step of the build of Xfree86 on Linux/i386, which

  consisted in producing Makefiles from Imakefiles, failed. With some rewriting,

  we managed to produce a Makefile for a simple Xfree86 command, <I>xclock</I>,

  and successfully compiled it. However, we did not spend much time on

  understanding the installation procedures of Xfree86, and, since it would have

  taken us too much time per command to rewrite every Makefile, we set aside

  Xfree86.</A></para>

  <para><A NAME="2574">Then we excluded one package, <I>groff</I>, because it was

  mostly coded in C++. We found also that some native Linux header files, used in

  several packages, offer BSD compatibility but in a way that could not be

  straightforwardly adapted to TenDRA. This issue is discussed in </A><A

  HREF="linux_re.htm#2743">&#167;  5.4</A>.</para>

  <para><A NAME="2577">We have included in the <I>level 2 </I>set of commands some

  commands which represent quite large amounts of source code: <I>m4, elvis</I>

  (a <I>vi</I> clone), <I>joe</I> (another editor), <I>less</I>, <I>perl</I>

  and <I>elm</I>. The ultimate step of this experiment would have been to build

  ``monsters'' such as <I>bash</I> and <I>emacs</I>.</A></para>

  <para><A NAME="2578">Finally, we evaluated the number of commands distributed

  with a Linux system, and we found about 700 executable binary files in the

  /usr/bin, /bin, /usr/X11/bin, /usr/openwin/bin, /usr/games, /sbin and /usr/sbin

  directories. We examined some of these commands in the Slackware packages, and

  concluded that there could be candidates for ANDFization. But we were limited by

  time constraints to include such commands. Also, we did not port to the 2nd

  platform, nor validate, all the commands operational on the 1st platform. Here

  again, time is the main reason why we did not complete the port. We estimate

  that an additional 1.5 engineer-month would have been sufficient to complete the

  task, apart from some commands which may have been difficult to port.</A></para>

  <para><A NAME="3621">The <I>level1 </I>and <I>level2</I> set of commands

  include 236 commands: these commands were installed and validated on Linux/i386

  (cf. section 4.7 on this point).</A></para>

  <para><A NAME="6370">In the list below, the commands in <B>bold</B> (149) have

  been installed and validated on both Linux/i386 and Linux/Alpha, as opposed to

  the commands listed in plain characters, which are available on the first

  platform only.</A></para>

  <para><A NAME="6384">The few (13) commands listed in <I>italic</I> were ported

  to both platforms, but their validation failed, or was not completed, on the

  second platform.</A></para>

  <para><A NAME="6390">Finally, in the `[p out of m]' statements, p is the

  best-case number of commands we ported, while m is the maximum number of them

  with respect to a given Slackware Linux package.</A></para>

  <para><A NAME="3592"></A></para>

  <itemizedlist>

  <listitem>aaa_base package [9 commands out of 9]: fromdos, funzip, mtools, todos,