seeking tools: running system to kernel config
 

I've read about some sort of tools that help with kernel configuration.
Can anyone tell me anything about these?

It seems that you use the tool(s) on a running system. You use the running system for a while. The tool(s) gathers data and leaves bread crumbs. The tool(s) then process the bread crumbs to create a candidate config file for a fresh kernel build. The goal is a kernel build that contains parts you actually use and omits parts you don't use or don't need -- all the while using arcane knowledge of dependencies among various kernel features to (hopefully) avoid building a still-born kernel.

Merci d'avance,
~~~ 0;-Dan

get to a terminal this is best done from the CLI
"cd /usr/src/linux<kernel version> " "make help" or just "make menuconfig"
if your reusing you old kernel config file copy it from "/boot" to "/usr/src/linux<kernel version> " to ".config"
then do a "make oldconfig " I just accept the defaults in this I'm going to reconfigure the kernel any way
the easiest tool to use IMHO is menuconfig the fancy graphs just get in the way

there is also "make localmodconfig" this will build a kernel based on lsmod but you still need to run make menuconfig to add file systems,usb,CDROM or DVD,etc,etc modules not loaded at the time you run this
While this is easier it dose not do the whole job

Does this cause the modules I use to become "built-in" for the new kernel, or does it simply "force" loading of those modules?

I'm using the latest distro --> updates edition of the kernel and its associated config. There are so many settings. How do I discover which of them apply to my hardware -- years of research?

Merci d'avance,
~~~ 0;-Dan

just rhetorical: if using the latest stuff, why would you need to build your own kernel?

The output of the command will tell you what you need about your hardware.
Based on that you can revisit the current default configuration and decide what you would not need at all.
is another way to get to the current configuration.
"localmodconfig" could help here too

Almost all of the drivers in a distribution like Ubuntu are built as modules while only the ones needed for _your_ hardware would _need_ to be included in the initrd.
They by default include more than _you_ need.
If building your own you could save something there.

Only you know if it is worth the effort.

You can also do without an initrd if you make all the drivers needed to get your machine booted (processor, chipset, root filesystem, display...) built in, not modules.

Maybe not years of research, but it takes some time reading and learning.

As an added complication comes, that Ubuntu (or Debian...) uses its own tool to generate a installable kernel-package.
You can do without it going the standard route, but updates will be more difficult because the package management would not know about your home-grown kernel and constantly overwrite your changes to the bootloader, for instance.

Only you know if its worth it - you will learn though ;)

I want to simplify and add lightness to my tablet-PC workstation. If I have stuff on the disk, I want it to be stuff I use or have a high probability to want or need.

For example, at the application level, most games and asian language parts can go. My laptop won't ever RAID so I don't need those parts. A typical question might be, "I lack video horses for display super-duper. Which video and display parts can I discard and remove?" My harware is Intel, so can I remove ATI and Nvidia parts?

Compiz and other 3D desktop does not yet play well with "tablet-PC". I already know that I cannot remove compiz package(s) with desktop damage, but I learned how to turn it all off.

Do you understand my objectives now?

Cheers,
~~~ 0;-Dan

Well, the first comment was rhetorical really.

I get what you want - been there, done that.

If you build your own kernel, and only include things you need, it will get smaller.
As will the initrd.

After all, you only need to include one scheduler instead of all of them, only the filesystems you actually have, only support for the processor you actually have - and so on.

Whether it is noticable later ... rather not, but it may be - slightly.

You can build a kernel optimized for your processor - but all the software you are using still is pre-packaged and not that optimized.

You will also gain hardly anything - speedwise - by removing not needed parts like unneeded display drivers (ATI, Nvidia).
The same driver as before is used - the others are just there, unused.
If you dont build them it does not hurt - you just don't have them lying around - but they would not be used anyway.

It does not get any quicker from that.

And - IMO - it is quite a hassle to do that (your own kernel) in Ubuntu.
Or Debian, or any derivate therefrom - like Mint, which I liked much better.

I would have stayed with Mint - if there had not been this very thing.

...and some more...

I came from Gentoo, which was nice but too much work. For me.
Now I'm using Arch.
Still some work, not as much preconfigured and ready to use as Ubuntu or its kind, but very easily adaptable.
Which was more of a pain in Debian/Ubuntu/Mint...

My opinion:
do try it!
(the kernel thing, not Arch...)

But be careful to NOT remove the standard kernel and its failsafe companion.
Just build your own and add it to the bootloader, thus always being on the safe side should it not work the first time around.

Then try and watch if you notice a difference.
And then evaluate if that was:
- noticable
- worth the time you spent on it

...talk about _adding_ lightness ;)

I friend from times past drove CanAm sports cars. In auto racing,
"adding" lightness apparently is a common effort.

~~~ 0;-Dan