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.
Attachment:
signature.asc
Description: This is a digitally signed message part
