|
From: <sv...@va...> - 2005-08-29 04:39:50
|
Author: njn
Date: 2005-08-29 05:39:46 +0100 (Mon, 29 Aug 2005)
New Revision: 182
Log:
Add section about porting priorities.
Modified:
trunk/devel/platforms.html
Modified: trunk/devel/platforms.html
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/devel/platforms.html 2005-08-27 17:29:51 UTC (rev 181)
+++ trunk/devel/platforms.html 2005-08-29 04:39:46 UTC (rev 182)
@@ -10,27 +10,24 @@
<dl class=3D"spaced">
=20
<dt><b>x86</b></dt>
-
-<dd>Currently, the stable 2.4.0 release only supports=20
+<dd>The stable 2.4.0 release only supports=20
Linux running on x86 machines.</dd>
=20
+<dt><b>AMD64</b></dt>
+<dd>valgrind-3.0 supports AMD64 on Linux.</dd>
=20
+
<dt><b>PowerPC/Linux</b></dt>
-
<dd>Paul Mackerras has an experimental port of valgrind to
PowerPC/Linux which you can
<a href=3D"http://ozlabs.org/~paulus/">download
here</a>. Caveat emptor applies!
</dd>
=20
-<dd>In valgrind-3.0, support for 32-bit PowerPC on Linux is
+<dd>In the Valgrind-3.0 series, support for 32-bit PowerPC on Linux is
under development.</dd>
=20
=20
-<dt><b>AMD64</b></dt>
-
-<dd>valgrind-3.0 will support AMD64 on Linux.</dd>
-
</dl>
=20
=20
@@ -57,11 +54,70 @@
=20
<dt><b>FreeBSD</b></dt>
=20
- <dd>Doug Rabson and others haved done a fairly complete port. Snapshot=
s of
- the work in progress are at <a
+ <dd>Doug Rabson and others haved done a fairly complete port for x86.
+ Snapshots of the work in progress are at <a
href=3D"http://www.freebsd.org/cgi/ports.cgi?query=3Dvalgrind">this F=
reeBSD
page</a>. We hope to integrate this support into Valgrind at some
point.</dd>
=20
</dl>
=20
+
+<div class=3D"hr_brown"><hr/></div>
+
+<a name=3D"porting_plans"></a><h2>Porting Plans</h2>
+
+<p>Valgrind 3.X has the infrastructure to support multiple platforms. A
+platform is a specific (CPU,OS) pairing, such as x86/Linux or
+AMD64/Linux. Support for each platform involves some CPU-specific code,
+some OS-specific code, and some platform-specific code.</p>
+
+<p>Maintaining each port takes a lot of effort, more so than for most
+other programs. Valgrind is fragile due to the low-level nature of what
+it does. Also each platform port has CPU-specific code, OS-specific
+code and platform-specific code, and testing all the combinations is
+difficult.</p>
+
+<p>Because of this, we can only justify supporting platforms that are
+widely used. Unlike NetBSD or GCC, we are not interested in having
+Valgrind work on every platform in the known universe: the maintenance
+burden is too high. Therefore, porting Valgrind to different platforms
+is not simply a technical exercise: you also need to make a convincing
+case that the effort will be worth it, and that the port will be
+supported properly, at least in the forseeable future. The following
+table summarises our current porting priorities.</p>
+
+<table class=3D"form" width=3D"100%" cellspacing=3D"0" cellpadding=3D"3"=
border=3D"1">
+<tr><th> </th> <th>Linux</th> <th>*BSD</th> <th>Darwin</th> <th>Sola=
ris</th></tr>
+<tr><td>x86 </td> <td>done </td> <td>low</td> <td>high</td> <td>l=
ow</td></tr>
+<tr><td>amd64</td> <td>done </td> <td>low</td> <td>eventually?</td=
> <td></td></tr>
+<tr><td>ppc32</td> <td>in progress</td> <td></td> <td>high</td> <td></td=
></tr>
+<tr><td>arm </td> <td>low </td> <td></td> <td></td> <td></td></t=
r>
+<tr><td>mips </td> <td>low </td> <td></td> <td></td> <td></td></t=
r>
+</table>
+
+<p>There are experimental ppc32/darwin and x86/FreeBSD ports for Valgrin=
d 2.X.
+They could be made to work with 3.x with some effort. A (much less matu=
re)
+port for x86/Solaris is also being worked on.</p>
+
+<p>ppc32/darwin is a high priority; it would be great to have Valgrind =
running
+on Apple machines. Once x86/darwin machines become available, that too
+will become a high priority. amd64/darwin will presumably eventually be=
come
+important. Of the other table entries Arm/Linux or MIPS/Linux might be
+useful for embedded developers. x86/BSD, amd64/BSD and x86/Solaris are
+lower priorities.</p>
+
+<p>There are many platforms not mentioned here. Some are of little inte=
rest
+(eg. SPARC/*, */AIX). Some would be technically difficult (eg. IA64/*).
+In particular Windows is not under consideration here because porting to=
it
+would require so many changes it would almost be a separate project. Al=
so,
+non-open-source OSes are difficult to deal with; being able to see the =
OS
+and associated (libc) source code makes things much easier.</p>
+
+<p>This message states our porting rationale and current priorities.
+As ever we retain a flexible approach, and we are interested in hear=20
+your comments/porting needs if you have any.</p>
+
+<p>August 27, 2005.</p>
+
+
|