Platforms

BOINC is intended to accommodate participant hosts with a wide range of operating systems and hardware architectures. For example, the hosts may run many versions of Windows (95, 98, ME, 2000, XP) on many processors (486, Pentium, AMD) with many architectural extensions (ATI or NVidia graphics coprocessors). BOINC addresses the following goals:

• The system should avoid sending code that the host can't execute.
• Applications should be able to exploit specific architectural features, i.e. to use nonstandard instructions or coprocessors if available.
• Enough architectural information should be stored on the server so that statistics can be broken down according to specific features.
• Simplicity. The combinatorial explosion of versions and architectures should be excluded from the internals of BOINC.

A platform is a compilation target. A set of platforms is maintained in the BOINC database of each project. Each platform has a name and a description of the range of architectures it can handle. Each BOINC program (core client and application) is linked to a platform.

At the minimum, a platform is a combination of a CPU architecture and an operating system. Examples might include:

name	description
windows_intelx86	Microsoft Windows (95 or later) running on an Intel x86-compatible processor
linux_xxx	Linux running on an Intel x86-compatible processor
macos_ppc	Mac OS 9.0 or later running on Motorola PowerPC
sparc_solaris	Solaris 2.1 or later running on a SPARC-compatible processor

The name of a platform should specify a particular version (e.g. of an OS) only if it uses features new to that version. For example, the platform sparc_solaris2.8 should apply ONLY to SPARC machines running Solaris 2.8 or greater.

For simplicity, platforms are assumed to be mutually exclusive: i.e. an application for platform X is not assumed to work on a host running core client platform Y if X <> Y. The BOINC scheduling server will send work to a host only if there is an application version for the same platform.

There should be as few platforms as possible. For example, suppose that there are both Solaris2.6 and Solaris2.7 platforms. Then any host running the Solaris2.6 core client will only be able to run Solaris2.6 applications. Application developers will have to create versions for both 2.6 and 2.7, even if they're identical.

Handling architectural diversity

BOINC allows applications to exploit specific architectures, but shifts the burden of recognizing the the architecture to the application developer.

In other words, if you want to make a version of your application that can use the AMD 3DNow instruction set, don't create a new windows_amd_3dnow platform. Instead, make a version for the windows_intelx86 platform that recognizes when it's running a a 3DNow machine, and branches to the appropriate code.

It is, however, desirable to report architecture back to the BOINC server. This makes it possible, for example, to report average or total performance statistics for 3DNow hosts constrasted with other Intel-compatible hosts. This is done using the boinc_architecture() function from the BOINC API. This passes a string (project-specific, but typically in XML) to the core client, which records it in the architecture_xml field of the result database record. For example, the application might pass a description like

    <

Each BOINC project is free to create its own platforms. To avoid anarchy, however, Tools Each Platforms are maintained in the platform table in the BOINC DB, and can be created using the add utility.