OpenSolaris is
(finally)
available. I've been working on this every day I've been with Sun,
though others have spent years on the effort, and it's an amazing
milestone. Unlike most launches, though, this is the beginning of a new
effort rather than the end of one. As much as we've done already,
there's far more
left to be done before OpenSolaris can fulfil all our promises and
achieve all our goals.
One promise we have fulfilled today is our commitment to
make
OpenSolaris accessible to people without the money or desire to buy
compilers. Since most of Solaris is normally built with the
Sun Studio compilers, this meant we'd need either to provide the
compilers on the same terms as Solaris (also
required to build OpenSolaris sources), or modify the sources to build
and work with the GNU C compiler,
available with source and free of charge under the terms of the GNU
GPL. For reasons more illustrative of bureaucracy and
human nature than of technological difficulties, we were unsure almost
until the moment of launch whether we would be able to provide the
Studio compilers under acceptable terms; therefore, another engineer
and
I have spent the last two and a half months porting OpenSolaris to gcc.
At this point I had a nice writeup on inline assembly differences
between the Studio and GNU compilers. But it relies on source code that
isn't available yet - namely, the gcc-specific inline assembly files.
So instead I'll talk about why it happened that way and why it's
actually a good thing. I'll also talk about some straight-up bugs we
found in the process of porting.
We received word that a final Studio license had been agreed upon on
June 3 - just 11 days ago! The license is free-as-in-beer
and although somewhat vague seems reasonable enough. Of course, I
prefer using only Free Software and promoting it whenever possible (as
we're going with OpenSolaris), so I'd really rather use gcc. Our plan
of record was to make a merged workspace available as "official"
OpenSolaris. There were three sets of changes that needed to be merged
together in the last three days leading up to launch: the gcc changes,
which edit about 2500 files (mostly to fix compiler warnings), a large
wad of renames to support the separation of code we're releasing now
from that which we're hoping to release later (thousands of renames),
and the coup d'grace, the addition of the CDDL license block to over
24,000 files. In the end, this gigantic 3-way merge proved impractical:
there were over 1700 conflicts to resolve. Most are trivial and can
easily be automerged by TeamWare, our revision control system, but the
sheer volume and shortened schedule would have made adequate testing
impossible.
Instead of the three-way merge, then, we elected to take the minimum
amount of change we could: the addition of the CDDL blocks and the
separation of released from unreleasable source. That meant gcc
support would not ship in the "official" sources - but it could still
be
made available to the developer community. This is important for
several reasons - first, it illustrates an important principle: FCS
quality all the time. That is, if it's not good enough for a customer,
it's not good enough to be putback. Since there was no doubt in
anyone's mind that the gcc work was not ready for either, that meant it
also wasn't good enough to call OpenSolaris. Second, it offers us an
opportunity to provide a glimpse into the way projects work. One of the
most common questions we get is "so, if the gate always has to be
golden, how does any major work ever get done?" Like most people, we do
major work in "branches" off the trunk. TeamWare supports children of
children and merging of independent workspaces with common ancestry, so
that no complicated branching apparatus is needed as for CVS. What will
be available on the gcc project
page will be that project gate. You're invited to participate -
there are over 300 mostly very small bugs to fix.
One of the most significant kinds of bug we found were programs writing
into string constants, confirming Osborne's Law.
These programs ordinarily work properly because the Studio compilers
place the string constants in the .data section or some
other writable data section. The flag -xstrconst changes
this behaviour, placing the strings in .rodata or a
similar
read-only segment and thus also allowing them to be shared. This
reduces runtime memory usage but comes at a cost: buggy programs that
attempt to write to the constant strings will trigger a segmentation
violation and normally die. gcc acts as if this flag were always on,
and applies it to other const data types as well. The end
result is greater enforcement of correctness at the cost crashes.
Fortunately fixing these is very easy. For example, I fixed bug number
6281909 (you're supposed to be able to see bugs, too, but it doesn't
seem to include the bugs of interest) by fixing the selector
function not to assume it can write '=' and
'\0' into its arguments. Note that the correct use
of
'const' can help prevent this kind of problem.
The original article on inline assembly will appear when the source it
references appears - and you can help make that happen sooner: check
out
the gcc
project page.
Technorati Tag:
OpenSolaris
Technorati Tag:
Solaris
