1 |
On Tue, Sep 10, 2013 at 6:41 PM, Richard Yao <ryao@g.o> wrote: |
2 |
> 1. The kernel expects -fno-stack-protector to be the default. What will |
3 |
> the effect be on kernel configuration once -fstack-protector is the default? |
4 |
|
5 |
Nothing, since the kernel build system doesn't source make.conf. If |
6 |
somebody creates an ebuild that actually installs a kernel then it |
7 |
might be an issue, though it could be filtered if it is a problem. |
8 |
|
9 |
> |
10 |
> 2. We should make sure that -fno-stack-protector is a supported CFLAG. |
11 |
> This will make it easier to handle complaints from the vocal minority of |
12 |
> our user base that want every last percentage point of performance. |
13 |
|
14 |
No reason that it would be any less supported than -fstack-protector |
15 |
already is. |
16 |
|
17 |
> |
18 |
> 3. I would like to point out that we are talking about deviating from |
19 |
> upstream behavior and everyone is okay with it. Anyone who thinks we |
20 |
> should stick to upstream when it is not good for us should speak now or |
21 |
> risk being asked "where were you when..." whenever they try to use |
22 |
> upstream as an excuse to hold back progress. ;) |
23 |
|
24 |
I don't really see this as an issue - in general maintainers are |
25 |
expected to accommodate reasonable CFLAGS. This doesn't mean that |
26 |
arbitrary CFLAGS are "supported" so much as bugs should be taken |
27 |
seriously if they're really bugs. If -fstack-protector causes serious |
28 |
problems and this is inherent to the nature of the package/etc then |
29 |
just filter it. If it causes problems because upstream isn't doing |
30 |
things right, then this is no different than how things were 10 years |
31 |
ago when we were stomping out amd64 issues left and right (not working |
32 |
on amd64 wasn't a reason to mask a package for x86, but we didn't |
33 |
accept "upstream doesn't care about amd64" as an excuse). |
34 |
|
35 |
Staying close to upstream is a good philosophy in general. I don't |
36 |
think that means that we can't have reasonable CFLAGS. Otherwise we |
37 |
wouldn't set CFLAGS at all and would just use whatever defaults the |
38 |
upstream build system applies. We're a distro - doing integration |
39 |
work is a value-add, not a sin. If we aren't doing integration, then |
40 |
users might as well just do Linux-from-scratch. |
41 |
|
42 |
Rich |