[rawhide social experiments] kernel-source(code) package removed once again ... (was: How to build kernel-sourcecode-2.6.8-1.525)

[Arjan van de Ven]

On Sun, 2004-08-22 at 16:24, Axel Thimm wrote:

> Thanks for clarifying this, I thought 4KSTACKS was for making it
> impossible to run XFS filesystems w/o risiking corruption. Oh, yes, I
> forget XFS/reiserfs is not supported.

actually you make XFS-vs-4Kstacks sound really horrible. On lkml there
is some discussion by people who see problems, however in general these
people are using a much older gcc which seems to have more stack "bloat"
than the newer gcc we use. In addition, the regparm optimisation we use
also reduces stack use somewhat.


> Enforcing your policy by removing _the option_ to go back is

Andrew Morton asked me for a patch to remove the option at the time 4K
stacks got merged. Ideally there shouldn't be a choice, I mean, there
sholdn't be a kernel config option for every improvement that hits the
kernel, instead there should be the right one chose. The kernel does
have a lot of (non-driver) config options, but almost all of them are
for different tradeoffs (like server-vs-desktop choices like CONFIG_SMP)

> bad politics, especially when at the same time lkml discussed whether
> CONFIG_4KSTACKS should depend on CONFIG_BROKEN. What is there to gain
> by removing the option? Very wrong educational skills IMHO.

The patch has not gone into mainline yet because people still use the
older gcc's. That's most of what is stopping it right now. However with
the patches we add, non-4kstacks doesnt' seem to work (4g/4g for
example, but there are others like execshield) and I'm not interested in
debugging and fixing all those. It's a small effort for someone who
wants to debug that to back out the patch.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040822/0f2098e1/attachment.sig>