Bug 15837

Assigning to tmb but CCing docteam in case one of them could propose a new test. w unruh, maybe you could also propose such a new text? That would save our kernel maintainer time for other, harder, bugs.

Assignee: bugsquad => tmb
Keywords: (none) => Triaged
CC: (none) => doc-bugs

Wish I could. Unfortunately I am such a newbie, and read the file to get a hint as to how best to compile a kernel. I have tried the way suggested in the current README, and got totally lost in the infinite variety of choices in configuration, made mistakes, created unuseable kernels, etc. It would really be nice to have a usable minimal guide.

You are aware that the kernel self-documents its configuration via the Kconfig files ?  When you configure using "make (xxx)config", most (if not all) of the curses or GUI config facilities will display quite a bit of information about each CONFIG option if you ask.  The basic rule is that if you don't understand what an option does (even after reading the help), leave the default in place.

Perhaps README-kernel-sources is more specific than it needs to be.  There's no reason why any reference should be made to a bootloader in a document about configuring kernel sources.  All you really need is instructions on how to run "make (xxx) config", or a URL reference like http://www.linux.org/threads/the-linux-kernel-configuring-the-kernel-part-1.4274/ .

CC: (none) => ftg

Yes, I was aware of the Kconfig explanations, and the ability to accept the "default" options. However that still means that you have well over 1000 decisions you have to make, and sometimes the effects of the default are not obvious. Far better would be to start with the distribution's current .config, and to alter that in order to achieve the small kernel change you want. If I want to patch say the trackpad driver, having to make 1000 decisions in order to do so, without really understanding how choice A impacts choice B (and there are many interrelated choices in the kernel). The  stated purpose of the README is to help those who want to make some small change. It does not do so. 

And making sure that the kernel can actually be booted is surely a part of such instructions. Ie, both initrd (which has become a complete necessity to booting) and the bootloader are critical parts of making a new kernel, and it certainly should be part of any such README. Certainly if the README is going to simply parrot some completely generic instructions on kernel compilation, a web pointer might be more useful (even if useless to the reader who wants to accomplish some small task). If I want to have a kernel which supports my SuperHyperBooming sound card, I do not want to have to decide if I should choose a tickless kernel, or a 1000 Hz or a 50Hz kernel. Or whether kernel debugging should be switched on or off. The distro defaults, chosen by someone with far more insight than I have, I hope, are fine for everything except the support of my sound card. A guide as to how to do that would be useful (obviously more generic than my sound card example) even if only a pointer as to where to look for instructions.  

As an example, I recently had to try to make the kernel adapted to my new system, a Dell XPS13. Part of that was to disable the psmouse module. Unfortunately Mageia had decided to compile the psmouse driver into the kernel rather than as a module. Certainly going through a 1000 decisions was pretty a pretty inefficient and useless way of doing that and I would not have eneded up with a Mageia kernel. I liked Mageia's choices except that one choice. How do I alter the mageia kernel to change psmouse from compiled-in to module? That README helped not at all, while that was the kind of thing it purported to be directed to. (That it was the the CONFIG_MOUSE_PS2=y line that needed to be changed to CONFIG_MOUSE_PS2=m I would hardly expect the README to tell me, but once I knew that, it would be helpful if it told me how to change the .config and then how to compile the Mageia kernel, not some generic kernel,  with that one little change.)

And both "How do I label the new kernel to differentiate it from the stock kernel" and "How do I make the system bootable with the new kernel" are important aspects of that.

Mass-reassigning all bugs with "kernel" in the Source RPM field that are assigned to tmb, to the kernel packagers group, because tmb is currently MIA.

Assignee: tmb => kernel

Indeed it's quite outdated…

CC: (none) => thierry.vignaud

lilo references were just dropped