diff --git a/en/platforms/ia64/index.xsl b/en/platforms/ia64/index.xsl index 18131e8bb0..f0313f1b87 100644 --- a/en/platforms/ia64/index.xsl +++ b/en/platforms/ia64/index.xsl @@ -1,87 +1,87 @@ - +
McKinley die

Search the ia64 mailing list archives:

Table Of Contents

Introduction

The FreeBSD/ia64 project pages contain information about the FreeBSD port to Intel's IA-64 architecture; officially known as the Intel Itanium® Processor Family (IPF). As with the port itself, these pages are still mostly a work in progress.

Current status

The ia64 port is still considered a tier 2 platform. This boils down to not being fully supported by our security officer, release engineers and toolchain maintainers. In practice however the distinction between a tier 1 platform (which is fully supported) and a tier 2 platform is not as strict as it seems. In almost all aspects the ia64 port is a tier 1 platform.
From a developer point of view there's an advantage to have the ia64 port be a tier 2 platform for a while longer. We still have a couple of ABI breaking changes in the pipeline and having to maintain backward compatibility this early in a ports life is less than ideal.


 diff --git a/en/platforms/ia64/todo.xsl b/en/platforms/ia64/todo.xsl index 5a3e798f08..90c7d5d895 100644 --- a/en/platforms/ia64/todo.xsl +++ b/en/platforms/ia64/todo.xsl @@ -1,144 +1,144 @@ - +
Montecito die

Search the FreeBSD/ia64 PR database:

What needs to be done

This page tries to be the starting point for people trying to find anything that can be done. The order of the items on this page are not strictly an indication of priority, but it is a good indication. There are in all likelyhood tasks that are not mentioned here, but that should be done nonetheless. A typical example is the maintenance of the ia64 web pages... unfortunately.

Becoming a tier 1 platform

With two releases as a tier 2 platform, it is time to work towards becoming a tier 1 platform. This involves tasks as varied as:

  • Improve the installation process to take into account that there is already a GPT with an EFI partition, including other operating systems. The ability to add a FreeBSD entry to the EFI boot menu is also a nice thing.
  • Port the GNU debugger. It is sorely missed on a development machine and required on tier 1 platforms.
  • Port the X server (ports/x11/XFree86-4-Server). Not really required for tier 1 status, but one cannot truely do without if one wants to use ia64 as a desktop machine.

Ports and packages

A very important task for the success of FreeBSD on ia64 is making sure that users have something to run besides ls(1). Our huge ports collection has been targeting ia32 for the most part, so it is not surprising that there are a lot of ports that do not build or do not work on ia64. Look here for the most up-to-date list of ports that fail to build for some reason or another. Note that if there are ports depending on one or more ports that fail, those are not built and are not counted. A good way to help out here is to work on those ports that have a lot of ports depending on it (see the "Aff." column in the table).

Sharpening the saw

There are plenty functions (especially assembly routines) that have been written to provide the missing functionality without any consideration for speed and/or robustness. Reviewing those functions and replacing them if necessary is a good task that can be done concurrently and independently from other activity and does not necessarily require huge amounts of knowledge and/or experience.

Core development

On top of the high-level things that do not work or do not exist, there is also some rather involved rewriting to be done at the foundation and can potentionally affect all other platforms as well. This includes:

  • Improve UP and SMP stability by revamping the PMAP module. The low-level handling of VM translations needs to be improved. This involves both correctness as well as performance.
  • Basic device drivers such as sio(4) and syscons(4) do not work on ia64 machines that do not have support for legacy devices. This is a rather big issue, because it affects all platforms and may involve rewriting (big) parts of certain subsystems. Clearly a task that needs wholesale support and coordination.
  • Better handling of sparse (physical) memory configurations by not creating VM tables that span the whole address space, but rather cover the memory "chunks" that are present. We are currently forced to ignore memory because of this.