Difference between revisions of "Supported platforms"
(add stuff about compiler and library assumptions) |
(→Extent of support) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 9: | Line 9: | ||
A platform's appearance on the support list indicates that we will treat problems on that platform with the highest priority relative to problems on other platforms. It indicates the amount of resources that the MIT Kerberos Team is willing to expend to resolve such problems. Platforms not on the support list receive a lower priority. For example, a platform-specific problem reported on an unsupported platform will get preemptively closed unless accompanied by a very well-written patch that poses negligible integration cost for us. |
A platform's appearance on the support list indicates that we will treat problems on that platform with the highest priority relative to problems on other platforms. It indicates the amount of resources that the MIT Kerberos Team is willing to expend to resolve such problems. Platforms not on the support list receive a lower priority. For example, a platform-specific problem reported on an unsupported platform will get preemptively closed unless accompanied by a very well-written patch that poses negligible integration cost for us. |
||
| − | On the supported platforms, we expect that the code on the |
+ | On the supported platforms, we expect that the code on the git master branch will normally build and function correctly. Where a supported platform is a family of platforms, (e.g., Linux, BSD) the MIT Kerberos Team may not have daily access to, or expertise with, every specific member of that family of platforms. For problems peculiar to a mainstream member of a family of supported platforms, but not present on a specific platform for which we have equipment or expertise, we will expend more effort working with the originator of a problem and with the Kerberos community to reach a solution than we would for an unsupported platform. Problems that relate to a specific CPU architecture on a supported platform, even a CPU architecture that we lack access to, will receive higher priority than CPU-architecture dependencies on unsupported platforms. |
== Supported platforms == |
== Supported platforms == |
||
| Line 52: | Line 52: | ||
Retaining coverage of more "pure" System V derived OSes would be nice, but these are generally OSes that pose significant porting difficulties (e.g. HP-UX). We think that Solaris is sufficiently close to System V lineage for our purposes. |
Retaining coverage of more "pure" System V derived OSes would be nice, but these are generally OSes that pose significant porting difficulties (e.g. HP-UX). We think that Solaris is sufficiently close to System V lineage for our purposes. |
||
| − | === |
+ | === Portability assumptions === |
| − | We expect that any supported platform will provide a C compilation environment equivalent to a freestanding C89 (ISO/IEC 9899:1990) implementation. Support for the standard C library does not have to be complete, but we expect that substantially most of the C89 and SUSv3/POSIX.1 libraries is available. Freestanding language support for C99 (ISO/IEC 9899:1999) does not have to be complete, but we use some features such as <code>inline</code>. |
||
| + | We generally make some assumptions about the capabilities of the platforms we are willing to support. See the main [[portability assumptions]] page for details. |
||
| − | |||
| − | We expect that the <code>snprintf()</code> family of functions from C99 and SUSv3/POSIX.1 is available and either conforms to the standards or deviates from the standard behavior in one of a small number of ways: |
||
| − | |||
| − | * It may return -1 if the target buffer is not sufficiently large. |
||
| − | * It may treat <code>n</code> of zero or a null target pointer as an error condition. |
||
| − | |||
| − | On Solaris, precision specifiers on string formats in <code>printf()</code> family functions may count columns rather than bytes if the application is not compiled in a standard-conforming environment. We are investigating the security impact of this behavior. |
||
Latest revision as of 09:22, 27 July 2012
This page represents an official policy of the MIT Kerberos project. Edit this page only in accordance with changes agreed by the community; other changes will be reverted.
Contents
Extent of support
The word "support" here does not mean that the MIT Kerberos Team in any way provides commercial-grade end-user support for MIT Kerberos. This list of platforms is subject to change at any time, but we will make an effort to follow the principles described in the Rationale. Input from Consortium Sponsors will affect the list of supported platforms, particularly if a sponsor contributes resources (staff expertise, equipment, etc.) for that platform.
This list of supported platforms reflects our priorities for the functionality and portability of the cross-platform source code product. Special platform-specific products such as Kerberos for Windows (KfW) and Kerberos for Macintosh (KfM) are not addressed here.
A platform's appearance on the support list indicates that we will treat problems on that platform with the highest priority relative to problems on other platforms. It indicates the amount of resources that the MIT Kerberos Team is willing to expend to resolve such problems. Platforms not on the support list receive a lower priority. For example, a platform-specific problem reported on an unsupported platform will get preemptively closed unless accompanied by a very well-written patch that poses negligible integration cost for us.
On the supported platforms, we expect that the code on the git master branch will normally build and function correctly. Where a supported platform is a family of platforms, (e.g., Linux, BSD) the MIT Kerberos Team may not have daily access to, or expertise with, every specific member of that family of platforms. For problems peculiar to a mainstream member of a family of supported platforms, but not present on a specific platform for which we have equipment or expertise, we will expend more effort working with the originator of a problem and with the Kerberos community to reach a solution than we would for an unsupported platform. Problems that relate to a specific CPU architecture on a supported platform, even a CPU architecture that we lack access to, will receive higher priority than CPU-architecture dependencies on unsupported platforms.
Supported platforms
- Mac OS X, specifically a "Darwin" command-line build treating the OS as a typical UNIX platform, but potentially using some features specific to Mac OS X. This is not the same as OpenDarwin.
- GNU/Linux (as an OS family; currently Debian, Ubuntu, or Red Hat on x86_64 and x86)
- Solaris (SPARC or x86_64/x86)
- BSD (as an OS family; currently NetBSD on x86_64 and x86)
Generally we use gcc on these platforms, but will also use Sun Workshop compilers on Solaris to achieve compiler diversity.
The specific operating system releases we use will vary, but will typically be a formal release no more than two or three years old. Under some circumstances, the specific operating system release will reflect MIT-specific concerns such as which release is currently used in the MIT Athena environment.
Rationale
CPU architecture
Most x86 or x86_64 platforms except Mac OS X client can run on a virtualized host. If we want to aggressively minimize physical hardware, we need only retain a small number of virtualization x86 hosts and a possibly larger amount of Mac and SPARC hardware.
We desire a certain breadth of CPU architecture coverage to detect regressions related to byte order issues or word size issues.
Our desired CPU architecture coverage is:
{ 32-bit, 64-bit } x { big-endian, little-endian }
and can be most easily achieved by:
- SPARC (big-endian 32-bit and 64-bit (on v9))
- x86_64 (little-endian 64-bit)
- x86 (little-endian 32-bit; subset of x86_64)
Strict alignment vs non-strict alignment is also useful to test, but not enough to justify another full axis to the coverage matrix. Currently, SPARC gives us the benefit of having strict alignment, while x86 is non-strict. Additional factors such as fixed-size instruction word vs variable-size instruction word are not worth additional effort at this time.
Desired OS flavors
- Mac
- Windows (not directly addressed in this article)
- System V
- GNU/Linux
- BSD
Retaining coverage of more "pure" System V derived OSes would be nice, but these are generally OSes that pose significant porting difficulties (e.g. HP-UX). We think that Solaris is sufficiently close to System V lineage for our purposes.
Portability assumptions
We generally make some assumptions about the capabilities of the platforms we are willing to support. See the main portability assumptions page for details.
