lkml.org 
[lkml]   [2011]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2011-05-06 00:29    [W:0.145 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site