John Plocher wrote: > 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. >
I'd prefer to drop the the above sentence altogether. I really do think we want all of the "common" portable code to be 64-bit clean. > 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. > I'm not entirely convinced that we need to make this waiver explicit. Specifically, imported code is likely to already be 64-bit clean if it is used on 64-bit editions of Linux (amd64, alpha, probably other ports as well). Second, for "non-optional" programs that make up part of the core foundation (e.g. perl, sendmail, OpenSSL), the inability to use these programs on a 64-bit only port would represent a serious deficiency. (Conversely, the inability to use e.g. "unison" on a specific port might be unlikely to be noticed by many users of the port.) My preference here would be for language more along the lines of: "Generally, new and imported code should be 64-bit clean. However, there may be specific exceptions, especially for programs that are platform-specific. Any other cases where programs are not 64-bit clean should be considered a bug." > 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. > Why not patch releases? > 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. > I would change the above paragraph to read just: 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 implement this. > 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. > Can we amend that somewhat, with something like this: However, on processors which are capable of running 64-bit programs (e.g. amd64), feature disparity between the program running on one 64-bit capable processor (amd64) and another (sparcv9) resulting from the decision to deliver 32-bit support for one of those processors might be considered a bug, particularly if the limitation is likely to be noticeable to users of the utility. The advice given in section 6.1 may be particularly apropos. > 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() > Spelling of isaexec. > 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 > >
