Re: [block IO crash] Re: 2.6.39-rc5-git2 boot crashs

From: werner
Date: Thu May 05 2011 - 15:53:57 EST


On Thu, 5 May 2011 11:54:21 +0200
Tejun Heo <tj@xxxxxxxxxx> wrote:
Hey,

On Wed, May 04, 2011 at 11:40:33PM +0200, Thomas Gleixner wrote:
Yeah, I tripped over that as well. And the new shiny extra
CONFIG_CMPXCHG_DOUBLE misfeature Christoph nailed together is just
ignoring it as well. It's just more useless #ifdef and CONFIG bloat.

That whole this_cpu_* stuff seems to be designed by committee. A quick
grep shows that max. 10% of the implemented macro hell is actually
used. Can we get rid of all unused ones and bring them back when they
are actually required?

What happened there was more of lack of design rather than too much
design.


........


From the sight of an user, not of an programmer, my opinion about more and more config options and the design is:

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.

Then, in a 2nd step considering this, any configuration of the arch is becoming obsolete and should be reduced so much as possible. It was useful in the time of papertapes and punched cards to can pick out what one need, but nowaday we have enough memory that the kernel can be compiled ALWAYS including everything, and on run-time the kernel discovers and use only what's present. For the case if users in poorer countries have a 486 with 8 MB storage (long time ago I used Slackware on such computers), one should CAN alternatively choice to compile and deliver also small kernels. But as default - or spoken more generally if is compiled a huge kernel - then at run-time it simply should ignore what's absent and used what's present. This means, in this general case, ANY user configuration of hardware is obsolete, and as default should be compiled everything (and into the kernel, not as module, in-/output devices which nowadays can happen as boot devices inclusive for an installation). One should reduce the configuration to a very few number of basical items - such as, with/without PEA; low-memory system (that parameter is the only what matters for make impossible an huge everythingyes kernel); slow system.

There is a very good analogon to this. Some distros have a very complicated configurator, difficult for advanced user and impossible to install Linux for beginners. F.ex., SUSE has an elefantous poissen-green installer, with thousands of options and very mis-understandable, in what I (trying to help someone two weeks ago) was unable to create an install/root partition without to be sure not to loose the existing partition. This is a complete misconcept, hinders people to use Linux, put users in risk by a mistake loose his existing partition/files, and should be dumped completely !!! Principally, the installation can be automatical and thus have to be automatical; little adaptions the user can make later in the KDE control center. My distro, intended to be maximal easy, has no interactive installer at all, and produces a very good working system in 99% of the cases, full-automatically. For example, for what any partition configuration ?? The 1:4 LZMA-packed iso, unfold, gives a 20 GB system. Thus, the install program can search alone where to find 20 GB, without any question to the user. It searches on the primary, then on the secondary hard disk for 20GB unpartioned space; if not found, then it resizes and/or moves existing partitions to get 20 GB free, and then install the sistem. If really all disks are full with files, it goes in the rescue system with mc , and the user should delete some videos etc and restart the instellation. Even the keyboard language, system language, user name, internet id/passwords are found and installed automatically - the install program reads them out from any (in 99% existing) pre-existing Windows, Linux or Minix installation on the computer.

Thus, when I read many comments here in the kernel threads, I feel that the most kernel configs should be removed and the kernel should find out itself at run time what hardware is existing. Also, the functions of things like udev and hal should be automatized. It is a sick concept, that the kernel itself find all hardware, but one need an externel program like hal to interprete the kernel messages and install the hardware, what the kernel can and should do itself. Each kernel version simply should include an updated table, of existing/known hardware and their most adequade Linux drivers, and then, during identifying hardware at boot or hotplug, set up everything to use it.

The kernel is becoming more and more complicated, and before people loosing themselves in details, one should make it most easy possible, for the users and for the maintainers, and throw out unnecessary and too complicated or misconcepted things. Because at the same time more and more new hardware surges, and also the kernel config becomes more and more big, there is no alternative and should be started most early possible, to automatize and improve the kernel's runtime autoconfig and auto-hardware-managing habilities. And REDUCE THE HUMAN-DEPENDING PRE-CONFIG TO THE MINIMUM POSSIBLE. This satisfies also that Linux is tecnically good, but have to become more easy for the use-by-anybody. This should be considered for the whole politics/direction in what is going the kernel development.

---
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/