[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 05 May 2011 17:12:10 -0400
From: "werner" <w.landgraf@...ru>
To: Christoph Lameter <cl@...ux.com>, Tejun Heo <tj@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Pekka Enberg <penberg@...nel.org>, Ingo Molnar <mingo@...e.hu>,
Jens Axboe <axboe@...nel.dk>,
Andrew Morton <akpm@...ux-foundation.org>,
"H. Peter Anvin" <hpa@...or.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [block IO crash] Re: 2.6.39-rc5-git2 boot crashs
On Thu, 5 May 2011 15:09:04 -0500 (CDT)
Christoph Lameter <cl@...ux.com> wrote:
> On Thu, 5 May 2011, werner wrote:
>
>> As the 1st step, for can be compiled generic kernels
>>at all, the kernel
>> should have (and has) the ability, to discover at
>>run-time , what hardware the
>> individual user has, and to use only the corresponding
>>kernel subroutines.
>> F.ex. if subroutines for ELAN or MOORESTON were compiled
>>also, then the kernel
>> ignore them simply, if on run-time it discovers that the
>>user has a 486
>> computer.
>
> Yes indeed the kernel can detect that. And the code has
>fallback for
> the case that the processor flags indicate that
>cmpxchg16b is not supported.
>
> However, in this case the kernel configuration at build
>time was set in
> such a way (!CMPXCHG64 support but CMPXCHG_LOCAL) that
>generic fallback
> functions were used at compile time instead of the x86
>assembly that can
> do the fallback with run time detection. Thus the code
>to do the fallback
> was not compiled in. Frankly, I was not aware that such
>a case existed
> where one could disable cmpxchg64 in this way and was
>expecting that the
> runtime detection would always be compiled in for the
>CMPXCHG_LOCAL case.
>
>
Thus, things gone wrong because it's only half-consequent.
One should compile everything, and at runtime the kernel
itself detect the existing hardware and decides/uses just
what it need.
My (and many other users) mind on configuration is very
simple: I switch everything on, so that the kernel has
everything available, and in run-time it uses just what's
existing on the individual computer of the user.
Just if there occured an human configuration error, so
that something at run-time wasnt available, then one
should improve the above explained manner of use, reducing
human need/influence, compiling everything, and improving
the kernel's runtime detection and use/selection of its
adequade modules.
I saw plenty people (specially, beginners) loosing all
their files by overformating or repartitioning the
harddisk within a too-complicated installer. Many
interactive installers are not good understandable. And
many simple users don't know nothing about harddisks,
partitions, etc. You know all details inside your
washmachine, and you need to know it for use it ?? Linux
has to work also for stupid people. Thus, the
partitioning / formatting process of the installation is a
good example what CAN and HAS TO BE full-automatized, in
order to reduce human errors. If a typical distro is 5 GB
or 20 GB big, then the installer can and has to manage it,
silently and alone, to find or desocupy this space (and
more if possible) anywhere on a harddisk, silently and by
itself, so that it installs problemless for beginners
(while 'specialists' before the installation can desocupy
a certain space of the harddisk which then the installer
will find and use).
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.
---
Professional hosting for everyone - http://www.host.ru
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists