Spec: http://www.opensolaris.org/os/community/arc/caselog/2008/351/proposal
Draft Opinion (also below): http://www.opensolaris.org/os/community/arc/caselog/2008/351/opinion-draft-txt Notes: I will be out of electronic communication on vacation for the next 2 weeks This is a *draft* opinion intended to be used as context for a vote. It needs wordsmithing in several places, including the "not architectural" sections in section 4. Contributions of "better words" would be very much appreciated. I will catch up when (if?) I come back to civilization :-) -John ============= Draft Opinion ============= sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Switch SPARC GNU coreutils+bash from 32 to 64bit Submitted by: Roland Mainz File: PSARC/2008/351/opinion.ms Date: VOTE NEEDED Committee: Usual suspects: (John Plocher), Kais Bel- gaied, Mark Carlson, James D. Carlson, Gar- rett D'amore, Joseph Kowalski, Tim Marsland, Richard Matthews, Darren Moffat, Glenn Skinner, Bill Sommerfeld, Gary Winiger. Product Approval Committee: Solaris PAC solaris-pac-opinion at sun.com 1. Summary There are emerging processor architectures where supporting *any* 32-bit userland is problematic or impossible. There is a class of "limitations/bugs" in many utilities related to the use of 32-bit data structures. This case sets 32/64 bit expectations going forward. When applying these guidelines, consider that "Everyone can, most should and nobody must" use them. New code developed specifically for Solaris or OpenSolaris certainly should be 64-bit clean. However, code imported from another ecosystem shouldn't face that requirement; there's no question that it's highly desirable, but such code may bring other benefits that outweigh any deficiencies that not being 64-bit clean might induce. 2. Decision & Precedence Information The project is approved as specified in reference [1]. Projects following this policy may be delivered in minor releases of any consolidation. This project sets precedent concerning 64-bit binaries. 3. Interfaces The project exports no interfaces. The project imports no interfaces. 4. Opinion The architecture here is simple - we need to be able to sup- port 64 bit-only systems. This implies that it is a bug to not be 64-bit clean. We also have 32-bit systems we need to support, so it is also a bug to not be 32-bit clean. It may be reasonable to hold up code "we write" to a higher standard than code that "we import from elsewhere", but, in the end, this is a C-Team rather than ARC issue: The ARC expects things to build correctly on both 32- and 64-bit processor architectures, and it is up to the C-Teams and/or Distro builders to choose how they will actually build things. Projects importing exteral software should consider trying to compile 64-bit - and file bugs upstream if found. 4.1. Where do 64-bit binaries make sense? 4.1.1. On 64-bit-only processor architectures that do not support 32-bit code, we must produce 64-bit code. When porting OpenSolaris to a totally new ISA, perhaps one could skip the effort to build a 32-bit support, and *only* do 64-bit, because at that point, there might not be any need to support a legacy 32-bit environment. 4.1.2. On 64-bit processor architectures that support run- ning 32-bit code, it is acceptable to have a mix of 32- and 64- bit programs. The decision to provide 64-bit-only code, to use something like isaexec() to provide both 32- and 64-bit code, or to remain with 32-bit only code should be made on a case by case basis. On x86/x64 systems, we have historically shipped an OS that had the ability to boot and run the same OS image on both 32- and 64-bit capable hardware. This opinion does nothing to change that status quo. Converting everything to 64-bit isn't a mandate at this time. 64-bit binaries provide certain advantages in avoid- ing capacity limitations. These advantages come at a cost that's becoming less burdensome over time as system capabil- ities (speed, memory size, file system space) increase. The trade-offs are shifting to make 64-bit binaries enough more attractive that self-review may suffice for many cases that propose to replace 32-bit binaries with corresponding 64-bit binaries. But we are not at the point where we can support blanket "do it all" or "no conversions need review" asser- tions. 4.1.3. 32-bit-only processor architectures obviously can not run 64-bit code. This implies that the build system still needs to be able to produce 32-bit code, so things need to remain "32-bit clean" as well. As with the 64-bit note above, the economic imperitives may change such that 32-bit-only systems are no longer "interesting" - at which point this guidance will need to be updated. For now, deviations (either way) need justifica- tion and associated review. 4.2. The "case by case" analysis mentioned above needs to address the following issues: 4.2.1. Does the code have 32-bit limits? If so, are those limits addressable using mechanisms other than 64-bit conversion? If so, consider using those mechanisms to provide value on 32-bit platforms independent from a decision to convert to 64-bit. (i.e., large file awareness, instruction set, ...) 4.2.2. Is the code 64-bit clean? If not (due to source code design and implementation prob- lems), bugs should filed against it. 4.2.3. Are there other utilities that should all be con- verted together? Consider both within families (i.e., all the GNU utils) and across (all the various flavors of grep...) 4.3. Non-architectural issues 4.3.1. Bitness parity between utilities in a "family" or across the platforms supported by a release There was some discussion about whether we needed to convert complete groupings of utilities as subprojects, either because there was value in having like things be the same bitness or because having them be different might be a call generator (if gnugrep behaves differently on large files than does /usr/bin/grep...). In the end, the Committee did not see this "family grouping" as an ARC requirement. There was also discussion about bitness-related functional- ity differences across platforms - a 32-bit binary on x86 behaving differently than the same command on 64-bit SPARC, for example. This difference was seen by the Committee as being a natural differentiation between hardware platforms with different capabilities, and not something that needed ARC intervention. 4.3.2. Who gets to decide what changes get accepted into "OpenSolaris", especially ones that affect the way the "OpenSolaris Binaries" are built? One member asserted "The real issue is that this isn't a change for you, or even the community to decide. Where did you suddenly become "product czar" for Sun's Solaris product? I expect this self-review -> fast-track will simply disappear. Its a product decision. I think it was silly that you even suggested it. (Yea, I know the sources should be on the other side of firewall and probably there should be a community con- trolled distro, but that isn't the case.) 4.3.3. How to ensure that bitness regressions don't happen The project team was concerned that there might be source code regressions without some mechanism to ensure that the 64-bit clean work was used and tested. The Committee referred the project team to the C-Team to work out appropriate automation and testing policy and mechanisms to guard against such things. 5. Minority Opinion(s) None 6. Advisory Information 6.1. Limitations of isaecec() Some members raised concerns that we may be missing out on performance and features by not providing 64-bit versions of programs by default, on those platforms which can run both 32- and 64-bit programs (such as amd64). A good example of this is grep, where a 64-bit grep can support processing of larger files, and on amd64 may out perform the i386 version. The current solution to supporting run-time selection of the ISA for the binary, isaexec, has some known performance lim- itations, and may not scale well, particularly for programs that are executed frequently. Thus, the PAC is advised to initiate a project to find an alternative to isaexec that offers run time ISA selection, without less performance impact than isaexec, and to make wider use of that alterna- tive to provide 64-bit feature parity between both platforms that are only 64-bit kernel capable (e.g. SPARC) and dual- mode platforms running in 64-bit mode (e.g. amd64). 6.2. 64-bit time_t on 32-bit systems Some members also raised concerns about a class of bugs related to the fact that 32-bit kernels, and 32-bit programs as a result, are only able to keep time in 32-bit sized integers. This can create problems, and bug disparities between 32 and 64-bit versions of programs such as touch(1). The PAC is advised to initiate a project to provide 64-bit timekeeping and associated system calls (such as lstat64_2(), utimes64(), or such) to 32-bit kernels and 32- bit userland. 7. Appendices 7.1. Appendix A: Technical Changes Required None 7.2. Appendix B: Technical Changes Advised None 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2008/351. 3. Proposal File: proposal Mail log File: mail PSARC/2008/351 Copyright 2008 Sun Microsystems
