| 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 |
Archives