.de Sc
\\s-1\\$1\\s0\\$2
..
.ds cA 2008/351
.ds aR \s-1PSARC\s0
.LP
.so ../../amac
.Co
.ds LF \fI\*(aR/\*(cA\fP
.ds RF \fICopyright 2008 Sun Microsystems\fP
.if n .ds CF
.IP \fBSubject:\fP 15
Switch SPARC GNU coreutils+bash from 32 to 64bit
.IP "\fBSubmitted by:\fP" 15
Roland Mainz
.IP \fBFile:\fP 15
\*(aR/\*(cA/opinion.ms
.IP \fBDate:\fP 15
VOTE NEEDED
.IP "\fBCommittee:\fP" 15
Usual suspects: (John Plocher), Kais Belgaied, Mark Carlson, James D. Carlson, Garrett D'amore, Joseph Kowalski, Tim Marsland, Richard Matthews, Darren Moffat, Glenn Skinner, Bill Sommerfeld, Gary Winiger.
.IP "\fBProduct Approval Committee:\fP" 15

Solaris PAC
.br
solaris-pac-opinion@sun.com

.pn 2
.NH
Summary
.LP

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.

.NH
Decision & Precedence Information
.LP
The project is approved as specified in reference [1].
.LP
Projects following this policy may be delivered in minor releases of
any consolidation.
.LP
This project sets precedent concerning 64-bit binaries.
.NH
Interfaces
.LP
The project exports no interfaces.
.LP
The project imports no interfaces.
.NH
Opinion
.LP
The architecture here is simple - we need to be able to support 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.

.NH 2
Where do 64-bit binaries make sense?
.NH 3
On 64-bit-only processor architectures that do not support 32-bit code,
we must produce 64-bit code.
.LP
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.

.NH 3
On 64-bit processor architectures that support running 32-bit code, it is
acceptable to have a mix of 32- and 64- bit programs.
.LP
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 avoiding capacity limitations.
These advantages come at a cost that's becoming less burdensome over time
as system capabilities (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"
assertions.

.NH 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.
.LP
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
justification and associated review.

.NH 2 "case by case" handling
The "case by case" analysis mentioned above needs to address the following
issues:

.NH 3
Does the code have 32-bit limits?
.LP
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, ...)

.NH 3
Is the code 64-bit clean?
.LP
If not (due to source code design and implementation problems), bugs should
filed against it.

.NH 3
Are there other utilities that should all be converted together?
.LP
Consider both within families (i.e., all the GNU utils) and across (all the
various flavors of grep...)

.NH 2
Non-architectural issues
.LP
.NH 3
Bitness parity between utilities in a "family" or across the platforms
supported by a release
.LP
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 functionality 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.

.NH 3
Who gets to decide what changes get accepted into "OpenSolaris", especially
ones that affect the way the "OpenSolaris Binaries" are built?
.LP
One member asserted
.RS
"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
controlled distro, but that isn't the case.)
.RE

.NH 3
How to ensure that bitness regressions don't happen
.LP
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.

.NH
Minority Opinion(s)
.LP
None
.NH
Advisory Information
.LP
.NH 2
Limitations of isaecec()
.LP
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 limitations, 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 alternative 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).

.NH 2
64-bit time_t on 32-bit systems
.LP
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.

.NH
Appendices
.NH 2
Appendix A: Technical Changes Required
.LP
None
.NH 2
Appendix B: Technical Changes Advised
.LP
None
.NH 2
Appendix C: Reference Material
.LP
Unless stated otherwise, path names are relative to the case
directory \*(aR/\*(cA.
.IP 3.
Proposal
File:
proposal


Mail log
File:
mail