Re: [gentoo-dev] [PMS] Add RESTRICT="distcc" capability

[Gordon Malm <gengor@gentoo.org>]

On Sunday, November 2, 2008 03:26:14 Ciaran McCreesh wrote:
> On Sat, 1 Nov 2008 18:29:03 -0700
>
> Gordon Malm <gengor@gentoo.org> wrote:
> > You're the one assuming the only purpose would be to mask parallel
> > make problems.  Apparently it does have a purpose though since
> > avidemux builds fine in parallel but NOT via distcc.
>
> 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?

>
> > Back to your most recent post
> >
> > >  *If* there's a legitimate use for RESTRICT=distcc then I am
> > > entirely in favour of it. But it looks like there isn't, with every
> > > issue being either a parallelism issue (which RESTRICT=distcc won't
> > > fix), a user configuration issue (which RESTRICT=distcc won't fix)
> > > or a hardened toolchain bug (for which RESTRICT=distcc is massive
> > > overkill, and thus the wrong solution). You've decided upon a
> > > solution before you've worked out what the problem is.
> >
> > You assumed it is a parallelism issue that people are trying to
> > solve.  I haven't pointed to any user configuration issues.  Using
> > RESTRICT=distcc on kernel modules is hardly overkill.  This isn't
> > openoffice.  I know exactly what the problem is, but since you have
> > such a better grasp on it....
>
> 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.

>
> > We have to build using different specs sets for kernel code than
> > userland.  If we can't depend on the __KERNEL__ macro for detection,
> > how else do you propose one detect if gcc is building kernel code or
> > not?
>
> 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.

We can't just hack the eclass to pass -fno-PIE because a particular package 
might build more than just the kernel module itself.  Patching kbuild in our 
sources doesn't address any modules that don't use in-tree kbuild and is 
stupid in so many ways anyway.  That leaves patching every out-of-tree module 
in portage manually and maintain those patches forward which would be very 
time/effort intensive on an ongoing basis.

Go ahead and forget about it though.  I'm done with this discussion.  Because 
we rely on the __KERNEL__ macro to determine which flags to apply, it only 
makes sense to patch in-portage distcc in the case of hardened to pass it.  
And that's exactly what I'll be doing.  Problem solved and I like that option 
better anyway.  Sorry to everyone who e-mailed me who thought RESTRICT=distcc 
would be somewhat useful.

>
> > I guess the larger question in all this is why does a third party who
> > has demonstrated his anti-Hardened (and anti-Gentoo) slant on
> > multiple occasions define what goes in our PMS?
>
> 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. ;)

Gordon Malm (gengor)

P.S.  I've seen enough of these threads from you to know that you can't help 
but respond with another post that does a lot of objecting but offers no 
solutions.  Go ahead and post again so you can feel like you had the last 
word, now is your chance, I won't be posting back.