Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 135001 - Genkernel: Some ideas to make it better and more effective
Summary: Genkernel: Some ideas to make it better and more effective
Status: RESOLVED LATER
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: genkernel (show other bugs)
Hardware: All Other
: High enhancement (vote)
Assignee: Gentoo Genkernel Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-31 02:04 UTC by Daniel Tourde
Modified: 2006-06-09 07:43 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Tourde 2006-05-31 02:04:43 UTC
Hello,

This is not really a bug report, more some thoughts about Genkernel (the good parts and rest...), about how it could develop to be even more effective and useful.
First of all, I want to say that I am neither a developer nor a kernel specialist. I am more a power user with a rather good knowledge of Gentoo and its administration. I have installed it on several system (laptops, desktops, 32, 64 bits etc...) and genkernel has been a very useful tool for me. I just want things to work and I have no interest/knowledge whatsoever in the inner flags/options of the kernel.

I consider the compilation of a kernel a necessary pain. The configuration is complicated, with so many cryptic options which can only be understood by specialists in PC hardware and computing science. Often I am confronted to problems having their root on a missing option/flag in the kernel (no USB printer support by default on AMD64 for instance...). Then I need to dig and guess, and try again... :(
On old machines the compilation can take a few hours, that's right and that can also be seen as an issue but honestly, there is no fun in reconfiguring and rebuilding the kernel again and again because an option was forgotten here or badly chosen there...
For me 'genkernel' is really a fabulous solution. I type 'genkernel all' and that's it... But does it really do everything I want?

IMHO Genkernel has a major flaw: the nature, structure and content of the profiles.
I explain myself:
At the moment, profiles are divided by platform and kernel versions. They have been created for certain versions of the kernel (2.4.y, 2.6.z) and their maturity depends highly on the popularity of the platform.

What I do when I build a machine, I run 'genkernel all' a first time, test the results and add some flags here and there for functionalities/drivers that are missing. The problem is that I am never sure I did everything right or that I did not forget something.
From then, when I rebuild a kernel (new version for instance), I _systematically_ use the latest configuration I have in /etc/kernels, independently of what is happening with the original profile from genkernel. In other words, I miss all the corrections brought to the profile. This is unfortunate.
Kernel 2.6 is an evolutive creature. Every 2.6.y release brings something new compared to the previous one. Does the profile reflect it? Using the profile I have in /etc/kernel, I systematically misses the functionalities. This is also unfortunate.

An ideal profile should be highly modular. It should contain the minimum possible inside the kernel (the flags marked * in menuconfig) and ALL the rest should be marked as modular (M). Who cares about a kernel that takes a few more minutes to compile because of a large amount of drivers? As long as it has to be done only once! (and not several times because of a missing module/function) for a given hardware. Linux is good at determining where it is and loading modules. So, let's make use of it!

Profiles should be separated in few simple groups, easy to understand and grasp for every non-kernel specialist:
- Desktop (where the kernel (preemption options and stuffs like that) is desktop oriented and all drivers, etc are modules)
- Laptop (laptop oriented kernel + all the rest as a modules)
- Server (bis repetitas)
- SMP machines (bis repetitas)

Profiles should be separated and updated (or at least dated) in view of the .y (like in 2.6.y) kernel they are associated too.

From the kernel builder perspective we would have something like:
genkernel --profile=laptop all
genkernel --profile=server all
etc...

genkernel being able to pick up the right profile adapted to the kernel 2.4.z, 2.6.y, where changes brought by y, compared to y-1 would be taken into account.

The advantage of such a system? Kernel specialists could provide perfect profiles (or we could borrow the ones from Ubuntu, Knoppix, RedHat whatever). Those who want to dig in the kernel configuration and tune it could do as usual, but the other ones, like me, who are just interested in a kernel that works optimally with the hardware at their disposal and at once would be relieved.

RedHat, Knoppix, SuSE have a good hardware support because every single module is built. It is a major waste of time and productivity to dig in the kernel configuration and this is a problem for gentoo. The kernel is vast and requires very specific knowledge. Why put this burden on everyone? Let's make genkernel better! Let's improve the profile concept.

Daniel
Comment 1 Chris Gianelloni (RETIRED) gentoo-dev 2006-06-09 07:43:08 UTC
There is a rewrite to genkernel in the works that has support for stackable profiles.  Needless to say, this was exactly what the genkernel developers have been planning for months now.

As for the profiles, on at least x86/x86_64, the kernel configurations are identical to what was used to build the LiveCD (not InstallCD) so it simply supports all of the hardware/options of the latest release.  They generally are not updated beyond that.