A way to detect all hardware, perhaps with an lspci/lsusb et al., or even lower level methods and then automatically remove the rest of the hardware from the .config, if one choses to do so.

There is an excellent site to help you with PCI devices - http://kmuto.jp/debian/hcl/. Google will help you with USB devices, too.

You don't get it. I don't have a problem manually finding the devices. I'm talking about a system that automatically removes drivers for hardware not currently existing on a system when creating the .config of the linux kernel.

But nevermind, I made a feature report.

Have you had a look at the localmodconfig and localyesconfig options?

Awesome! though I'm currently on windows, I'll see later. hehe.

I wonder if there might be a bit of a catch-22 situation here: you need operational drivers to know what devices are out there; for the software to see them.

Usually, I boot up a Knoppix DVD on a strange system and notice what drivers it comes up with. What definitely would be nice would be some tool to automate the result of that discovery process, perhaps writing a text-file to a conveniently inserted thumb drive.

You don't need working drivers to see a device (otherwise we really would have a problem with all the people here with wireless problems), all you need is an up-to-date database for lspci/lsusb. But of course this only helps to determine which hardware is present, but not which driver is needed for that hardware, localmodconfig and and localyesconfig therefore are only looking which drivers are currently loaded and create a config file for those drivers.

That's actually not very bad since it's excellent for situations like debian unstable or experimental:

e.g. I download 3.8.3 from experimental debian, it has EVERYTHING as a module (or built-in when they can't), so there a method like that would make a tiny .config compared to before.

Right now it's extremely gruesome because you have to go through around 40minutes+ in most systems to recompile a kernel for your processor, CFLAGS, or other minor different settings.

The alternative of going manually is also gruesome not so much because it's impossible but you can't really do it once. After 6 months it might need another trimming since the structure of the kernel itself might change (it has happened a lot especially after major 2.x releases).

Though of course I don't know if that method is quirky (e.g. creating problems with built-in features etc.), I haven't seen it in action.

Ok it works quite well!

I realize that even if not as dynamic as the first idea, the localmodconfig method (introduced somewhere in 2.6.x) might satisfy that need for most situations a kernel is already configured to be modular and one only needs to base a custom local kernel on that generic installation. e.g. when basing it on debian kernels that basically include everything they can as modules.