On Sun, 2 Nov 2008 12:11:10 -0700 Gordon Malm <[EMAIL PROTECTED]> wrote: > > Have you conclusively established that they do build fine in > > parallel? If so, how? And why do they break in parallel only under > > distcc? Given how distcc works, this strikes me as somewhat > > implausible... > > Yes it builds in parallel. By compiling it in parallel. I don't > know why and don't care to investigate for you. It's not my package, > I'm not QA and my team is short staffed enough as it is. We have to > take care of our own backyard. Maybe you could investigate the > answers to your own questions? How about you at least feign attempt > at answering my questions for a change?
If you think compiling it in parallel confirms that it builds in
parallel, you're reaffirming my growing suspicion that you're entirely
wrong about distcc being responsible for anything other than hardened
brokenness...
> > RESTRICT=distcc on kernel modules is unnecessary for the large
> > proportion of users who don't use hardened. RESTRICTs can't be set
> > dependent upon whether or not something like hardenened is enabled;
> > other mechanisms are available that can be. So why aren't you
> > considering those other mechanisms?
>
> I agree with the first sentence, never said otherwise. Who says I am
> not considering them? In fact, I have stated that I am. They are
> just more hackish than adding the ability to RESTRICT distcc, hence
> my reason for soliciting such a feature. I'm surprised that you'd
> suggest this after debasing a RESTRICT option on the same grounds.
And that brings us to the other thing you don't understand: RESTRICT is
a global, system independent, invariant metadata key. Things in
RESTRICT are in RESTRICT because they have to be known in situations
where those constraints are in effect. Things that do not have to be
known at the metadata level shouldn't be in metadata.
> > A macro is just a macro. All it does is affect the preprocessor
> > stage. Hardened is trying to abuse it for something else entirely,
> > which is why you're encountering problems.
>
> You can cry "abuse" all you want. You FAIL to offer any alternatives
> or solutions. I'll ask again, how do you detect that you are
> compiling code destined to be run in-kernel from within gcc without
> checking for the __KERNEL__ macro? I think we both know the answer.
I suggest you talk to hardened upstream and see what they have to say
about it. What have they offered as justification for using -D in a way
in which no-one else uses it? What are their objections to switching to
an approach that doesn't break the preprocessor model?
> Sorry to everyone who e-mailed me who thought RESTRICT=distcc would
> be somewhat useful.
Those people are mistaken.
> > Uh, that's your answer to technical objections to a proposal? You
> > aren't prepared to defend your proposal on its merits?
>
> Why are you assuming this point is *at all* related to my proposal?
> It's not. It's about Gentoo. But I stand corrected, a bunch of
> people rushed to tell me you don't actually determine anything. ;)
So you don't care about whether your solution is right?
You are proposing to add a metadata invariant option for a condition
that isn't metadata invariant and that, by being made metadata
invariant, means it's being disabled for everyone rather than by the
small number of users who might need it. In addition, you can't
demonstrate any cases where this option is genuinely useful, other than
as a workaround for a hardened bug that you haven't contacted upstream
about, and when used to work around said hardened bug the scope of the
change isn't limited to hardened.
You still haven't explained why you don't do something like:
broken_hardened_compiler && export DISTCC_HOSTS=localhost
--
Ciaran McCreesh
signature.asc
Description: PGP signature
