How to create kernel config to suit specific hardware?

[Michael_AU]

A bit of background before I get to my question. I have been working with kernel devs to fix an issue that was broken after kernel 2.6.32. On X86-32 Panasonic Toughbooks with multiple PCMCIA card slots (CF-29 and older) both card slots worked on kernel 2.6.32 and earlier but all kernels after 2.6.32 the top card slot doesn't work. With the help of kernel devs we are working out how this is going to be fixed. Therae is a patch that introduces a kernel quirk that fixes the issue but it will probably break other hardware if it is introduced. I am in the middle of compiling a kernel with the mmc_ricoh_mmc option switched off to see if it works. If It does I will report back to the kernel devs and go from there.

Now to my question, is there a way, apart from going through a blank kernel config line by line, in Debian to create a config script that only enables hardware used by the target machine? similar to the expert install option of only enabling hardware specific modules? The kernel will be used in a live-build iso to be installed on specific hardware so having a hardware specific kernel will help to minimise kernel bloat and also help to make older Toughbooks more efficient.

[Head_on_a_Stick]

is there a way, apart from going through a blank kernel config line by line, in Debian to create a config script that only enables hardware used by the target machine?

Code: Select all

make localmodconfig

[Michael_AU]

is there a way, apart from going through a blank kernel config line by line, in Debian to create a config script that only enables hardware used by the target machine?

Code: Select all

make localmodconfig

Thanks for that, I was under the impression that this only enabled modules that were being used at the time the code was called so for example if a GPS unit wasn't being used the module wouldn't be loaded and therefor make localmodconfig wouldn't enable it in the new kernel build. Am I wrong with this impression?

[Deb-fan]

Think "make localyesconfig" is closer to what you're shooting for, does same as Head_on's which is a good suggestion too. Only it takes the running system and sets kern configs to =y(built in.) Seems somewhat, what you're trying for. Just made a .config with it using the 4.19.bpo kernel with a 5.4.2 kernel source (kind of silly on a 10yr old laptop I guess.) Yep does strip out much chuff, though still some left and more than a few gotcha's or limitations. One biggie, is in supported filesystems, I use ext4, when getting to the section for choosing which filesystems are supported everything but Ext4 was gone, so no fat32 for usb sticks, fuse, overlay etc. Missing varied compression formats you may want to use at some point. Things like disk i/o scheduler, power governor, congestion control algo's etc, are supported and set default, a person is left with what's selected in the running kernel and are built in and none of the others even supported. Other stuff which someone may wish to mess around with too. Like timer interrupt freq (250hz vs 1000), preemption model, memory allocator, LSA (linux sec agents) ie: SElinux, apparmor, yama what's set as default or which of them are supported, I tend going with discretionary access control for default sec model.

Still this gets you closer to where you're wanting to go. Comes to custom kernel's just doesn't seem there's any getting around devoting time/effort to understanding it. I'm still a long way away too. Of course I looked for some mystical shortcuts, scripts and commands which would make it 1, 2, 3 and wasn't able to find such. After doing this "make localyesconfig" ... run "make menuconfig" choose "load", it loads the .config made my "make localyesconfig" and explore the configs set in the .config file it produced. So you can modify it, make whichever changes and save the thing before exiting menuconfig. You can always go back into the build directory and fiddle with it some more later. After exploration and googling up on what's what. In menuconfig, there is a help option for every config that'll give some information about what it is/does, sometimes makes suggestions as to what to set them at too. And if you know the name of the config option you can always hit the "/" type it's name and menuconfig will tell you which section-etc that config option is located.

To tell the truth don't feel overly confident chatting about this too much, am nowhere near any type of guru on the topic. Really it's mostly harmless though, could just end up with a kernel which fails to build, complete's but has a kernel panic at boot or ends up missing support at some later date for something etc. Definitely takes time/effort ... Linux kernel is the product of decades of uber-geeks pouring their time and talent into the thing. Logically not going to be a wham, bam ... done in 2hrs affair getting it down. When executing "make localyesconfig" it'll run you through whatever new config options have changed against the running kernel used. Can make selections for them =y (yes built in), =m (module), =n(not supported)or just hold down Enter/Return key to accept default and dork with them later in menuconfig. Think it makes most sense to use a running kernel as close to the kernel version someone is trying to compile as they can. Install and do this with the same version of that kernel from the repo's, as the one you're going for. Getting rid of a bunch of the chuff from jump is bound to cut down on compile time though.

Curious to see how it'll come out, how long in terms of compile time, know it'll build, have done same version on this old thing for hades of it. Though I've got a Broadcom/wl.ko wireless module headache I've got to research or PM Stevep and ask him for some of his compilation, backporting wizardry wisdom. Keep at it OP, only way to learn is try and any failure is just a part of paying your dues for the geekcred and any bennies involved.

[Head_on_a_Stick]

I was under the impression that this only enabled modules that were being used at the time the code was called

Not quite. The command will include any modules that are loaded so you just need to plug in any and all devices that you need before running it.

Have you seen https://kernel-team.pages.debian.net/kernel-handbook/? It's probably better to build a .deb for the kernel.

[Deb-fan]

For some reason was thinking support being built in was a requirement. Probably cause when I'd posted all that, brain felt like oatmeal. Now after struggling with Broadcom's wireless driver hassle, still feels like oatmeal only with walnuts, still in their shells in it. However persistence paid off ... I won. Thanks for bringing this to mind guys. With either approach shown, will work but building in support for hardware not subject to change has got to be a main focus in even going through the process. Haven't confirmed that localmodconfig acts the same as the other (localyes-etc) but believe it likely does.

Those gotchas really have to be considered, tailoring a kernel to xyz-hardware definitely good though ending up with one that's extremely limited in functionality and isn't going to work well for many practical purposes, not so much. Yeah ... you'll need to go through menuconfig and make sure you've got what you need covered in the final .config file used.

In yer face Broadcom! Well on second thought dumping all that time upgrading a kernel on an ancient laptop that didn't need it, just to see if I could get Broadcom working with it ... not much of a win. At least know now lastest versions of dkms and broadcom-sta-dkms work with kernel v 5.4.19 (used the Debian source pkg) for the wl.ko module.

[Michael_AU]

Think "make localyesconfig" is closer to what you're shooting for, does same as Head_on's which is a good suggestion too. <snip>

I'll try this but I'm not convinced it will strip out things like apparmour etc.

With regards to 10 year old machines I have 3, 1 of which I got last year with only 80 hours usage on it. It might not be a rocket but it suits my purposes for tuning cars running ECUs like Megasquirt, I can also dual boot with FreeDOS and tune Delco ECUs with Kalmaker because they have older ports that I need. Other people in a small group I am working with run GPS software because it works quite well with modern Linux and even though a CF-29 can run Windows 10 (as long as your hardware includes an SSD and you absolutely max out the RAM to 1.5 GB) they are as slow as a slug with it.

I was under the impression that this only enabled modules that were being used at the time the code was called

Not quite. The command will include any modules that are loaded so you just need to plug in any and all devices that you need before running it.

OK will do, I'll have to get some of the group I am working with to run through their hardware to ensure I get it all.

Have you seen https://kernel-team.pages.debian.net/kernel-handbook/? It's probably better to build a .deb for the kernel.

I have and using the method they put in I am getting build failures, it keeps failing on PowerPC configurations but using my own CF-29 config their shouldn't be any PowerPC material. I was using another method late last year and it worked a treat but, for some unknown reason, I didn't bookmark it and cannot find it in my browsing history.

I appreciate your time and help and hope one day to be able to repay likewise.

[Deb-fan]

^ No worries, old tech can blaze with Debian, with Linux. Actually localyes-etc didn't mess over much with security options that stuff was left alone. Ended up like usual getting rid of much in the Security section of config options myself, cause it's bloat I never intend to use, SElinux, Yama, smack etc. Kept apparmor support just in case I'd ever want to use it but set DAC(discretionary access thingy) to be the default security model used for that kernel. Things I'm talking about is making sure there's support for much other stuff and what gets set as default ... what's used-avail for them. When the kernel is compiled.

Ie: Esp filesystems supported, if I go to use FAT32 or ext2 and support for those aren't config'ed into the kernel I'm running (not built in, not even with modular support) those filesystems won't work. Disk i/o scheduler, think the only option left using localyesconfig was mq-deadline, I want others supported too, bfq, kyber etc. Things like that, if support in kernel isn't available, someone is stuck with a limited kernel they can't use the ways they prefer. Makes a much less functional kernel. Mentioned this type of thing definitely gets someone closer, saves time not having to do it by hand big time, compile time etc though you'll still have to tweak the .config file you're going to use manually w something like menuconfig. To avoid ending up with a seriously limited kernel.

[Michael_AU]

Sorry for the extremely late reply. The pandemic has created havoc and money has been thin on the ground so my net connection has only just been reconnected.

This morning (Australian Eastern Standard Time) I compiled (created a deb) of Debian 4.19 with the mmc_ricoh_mmc flag switched off. I have given a link to my Toughbook friends to test it. If it works, as the Kernel devs suggest, I will start working on a stripped down kernel deb for the venerable X86 Toughbooks using your suggestions and will let you know how it goes.