Messages in this thread | | | Date | Fri, 6 May 2011 00:27:20 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [block IO crash] Re: 2.6.39-rc5-git2 boot crashs |
| |
On Thu, 5 May 2011, werner wrote: > 90% of the config options, users don't know for what they are. Instead of > more and more new config features in, EVERY CONFIG PARAMETER WHAT THE KERNEL > CAN DETECT AT RUN TIME (at the beginning of booting) SHOULD BE THROWED OUT. > And the kernel should be compiled 'everythingyes' as default. Even then, > with all exotic (but nowadays happening) boot-necessary input/output hardware > included, my vmlinuz is only 10 MB big. Sufficient memory for run this > (together with an initrd for an installer) nowadays should exist on almost all > computers. All other, not-boot necessary modules are perhaps 50 MB, and since > the Atari time with 20 MB harddisks passed, there is NO REASON FOR COMPILE > SMALL THE KERNEL. Even on Android phones, compiling the kernel / modules 50 MB > big but using often only a part, dont hurt. But for emergency, instead of > completely configless, one could let 2 options for the kernel config: normal, > small (below 16 M memory). Provisorically, one could but one should not > include such a raw-selection menu in the kernel config, because to check and > maintain the dependences of their various single config parameters would be > big extra work. Instead of this, one should rigorously make more and more > config parameters definitively obsolete and reduce them by improving the > corresponding runtime ability of the kernel.
Have a look outside of the x86 and "smartphone brag with your GBs of RAM" world and you'll see that there are
- systems which really care about size reductions which are measured in kilobytes.
- systems where runtime detection is impossible
- systems where runtime detection is complete overkill in various aspects: boottime, memory footprint ...
And you CANNOT put those requirements under a single CONFIG_VERY_SMALL=y fits it all thing simply because embedded devices have those fundamental different requirements vs. drivers, filesystems ....
Aside of that config options are a pretty useful mechanism to debug problems.
And in the context of that particular case you are barking up the completely wrong tree. The facts that
- slub used the wrong macro
- the CONFIG dependent x86 implementation of that this_cpu_* mess was crap to begin with
are not an argument at all to go and impose a 100MB/50MB/16MB or whatever arbitrary choice you make limit of CONFIG_FITS_IT_ALL_* approach.
That simply does not work.
Thanks,
tglx
| |