"C. Bergstr?m" writes:
> James Carlson wrote:
> > The political aspect, if there is one, is the development process
> > around all of this, which includes the rules for gatelings: you must
> > test, you must do so on all affected platforms, and you must do so
> > thoroughly. The political aspect of adding a new compiler to the mix
> > is that you'd be forcing every ON contributor to compile three times
> > instead of the current two -- just to make sure that your "open64"
> > support doesn't itself suffer bit-rot in the gate. That's not
> > necessarily a bad thing, but it's a non-zero change, and would take
> > work.
> >
> >
> Hi James..
>
> At the very least I appreciate your very insightful reply..
>
> Just because it compiles. .does it mean it boots? I *highly* doubt gcc
> gets anywhere near the same level of testing that suncc does..
Indeed, it doesn't get that level of testing at all.
The only thing we're guarding with the current development process is
that it successfully compiles with gcc. It took quite a bit of work
by a small army of people to guarantee _that_ much, and it was done
specifically for the benefit of folks who feel that it's necessary for
all bits to be open source, and not just a subset.
I agree that we could do much better here, if we had the resources to
test and deploy the gcc-built variant as well.
What I've been pointing out is that the path you're suggesting for
"open64" doesn't even result in the same level of "it still compiles
after the next project integrates" goodness. It works once.
> I've
> flippantly asked those who are more than gatelings if it does boot and
> I'm still waiting for someone to tell me a definitive yes.. and
> something more than "if it doesn't.. it's a bug" Yes.. others have
> worked hard at this, but still lets look at this /testing/ you're
> referring to.. kernel performance regressions.. You guys build and test
> the spec benchmarks.. you run them with SS12.. SSX, but do you use gcc?
Not for any project that I know of.
> Is there an internal policy on this?
The policies are all posted on the web site; the current one is that
it has to compile with the shadow (gcc) compiler.
> Now.. lets switch focus away from
> a corporate mentality and not care about onnv-gate or me pushing one
> line of code change or policy to ON...
I don't understand. I've been trying to address the issues you've
been raising ... I haven't been talking at all about corporate issues
or "mentality" or whatever it is you're on about now.
I think you might be imputing motives to others that just aren't
right. In any event, I can't "switch away from" something that I
haven't been doing.
> Part of my work isn't just
> screwing things up by using another compiler.. my work is at a high
> level also explicitly trying to lower the threshold for people to test..
> When something like crossbow drops. "what if" it was easy for people to
> install/test/cr.. would that mean more people do it.. Now say we have
> thousands of people doing this on more hw and sw variants than Sun does
> internally.. Who is going to get more testing? Not everyone is going to
> be interested in testing Andrew Morton's patchset, but slowly I work
> towards making things like this possible.. Right now people toss out cr
> and beg for review in some circumstances.. "what if" that whole process
> was easier... What if we have a fully open toolchain and a continuous
> build server so we *know* when who to blame when the bleeding edge
> commits a breaking change...
Lowering the barriers to testing sounds like a good thing, but it's
somewhat unclear to me how open source versus freely redistributable
binaries actually factor into the tool chain.
I *think* you're talking about a political position there. It's an
admirable one, and I agree with you that it'd be great if all source
were open, and that it's good to do things that move us (and others)
in that direction.
However, I don't see how solving that issue raises, lowers, or does
anything about the testing barriers, which have much more to do with:
- The expense and complexity of maintaining farms of test machines,
particularly for specialized targets (say, a machine with 192 CPUs
and multiple 10Gbps Ethernets).
- The difficulty in setting up unusual test configurations.
- The fragility and frankly low quality of some of the existing test
suites.
- The fact that some of the tests aren't available outside of Sun in
any usable form, binary or source.
- The requirement to have lots of third-party equipment for
interoperability testing.
These are serious issues, and I hope that they'll improve with time,
but I'm a little unclear on how adding a new compiler to the mix or
shuffling around a library helps. Maybe it does, but I don't quite
see it.
> This thread is completely off the original intent which is me asking
> about libCrun.so.. I have the answer to that now..
Uh ... yes. I'm pretty sure I didn't bring up open64, though.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
