Question: Getting rid of unneeded kernel options on Librem 14 #1229
Comments
|
@Unb0rn really interesting points @JonathonHall-Purism might want to look at. We had brief discussion in regard of my attempts in reducing kernel footprint and have some kind of guidelines for minimal requirements. Some joint efforts would be nice. I did #1184 on that matter (xx20/xx30 boards related) but there is a lot of options that are unneeded. Outside of drivers that are specific for specific boards, the same options should be deactivated/activated. |
|
Thank you for your #1184 work, I think it helped a lot It would be nice to know any opinions on them. I'm unsure if we still have some devices using CONFIG_ZONE_DMA and CONFIG_ISA_DMA_API as well as if it's okay to leave the kernel mute. I also discovered two more options: For now, I attached both full and partial configs. Ready to create a PR if @JonathonHall-Purism thinks its okay to use this config |
|
@Unb0rn i would suggest creating a pr which will create board librem roms automatically, to be easily tested, which will ease kernel config review consequently as well as regression testing possible in whatever subsequent changes. Cleanup can be done afterwards. This is a community project and we also need to lower the bar to have contributions, just like the ones you are proposing yourself, to add features you are needing for your own use case. This is exactly what this community project needs as input. On a side note, I would advise moving away from savedefconfig format, as a result from past discussions, to ease kernel version bumps in the future as well. Seeing what the config is for what it is, instead of its deviation from a specific kernel version's defaults, is needed to ease understanding without added misunderstood manipulations. I disagree with keeping savedefconfig for next commits of Kernel configurations under Heads and can refer if needed to past discussions under other issues: this format is counterproductive. So please do that PR giving full .config replacing librem share configuration across all boards. It will permit direct testing and collaboration on provided config file, and collateral impacts on other boards Linux configurations. |
|
Created the PR. Left the old defconfig until the time we're ready to merge - I can't be 100% sure that it works fine on other Librem machines... |
|
@Unb0rn replying here instead of in PR since this is the discussion that should lead to a final clean PR. I used your branch to produce savedefconfig so that boards can be built automatically for testing/comments. Waiting for you to pick up the changes so they can be reviewed/tested by Purism which own the boards under https://github.com/tlaurion/heads/tree/Unb0rn_savedefconfig_changes which, since I follow my Heads repo as a CircleCI project under CircleCI, builds roms for each of my branches/commits into my CircleCI instance instead of osresearch's. Note that since you placed the kenrle config outside of what is currently used inside of the board configurations, the CircleCI builds under your PR have not built your kernel config and are building master's shared linux librem config. In my branch, the linux config has overwritten master and is building roms for all librem boards under https://app.circleci.com/pipelines/github/tlaurion/heads?branch=Unb0rn_savedefconfig_changes Will also follow discussion and apply changes in cleanup/kernel bersion bump for other boards. I would also advise into tagging JonathonHall-Purism (adding @ before the name) when you want review from Purism. On your questions (@JonathonHall-Purism please comment as well): A really nice online resource to understand kernel options and dependencies for a kernel main version is https://www.kernelconfig.io Analysis below is theoretical: nothing better then having regression testing to see impacts of changes (hypothesis/verification):
I do not think its used. Would have to do regression tests with flashrom operations
I do not think its useful either?
ISA?!
Same
Well, networking backend cannot be completely removed (#564 (comment)). I am not aware that Librem have Ethernet device, but might be wrong. Idea there is that dropbear, busybox (wget and other network components) would require networking, and if such networking is enabled, then networking should at least include basic security config as well. I think it should be safe to keep it if networking is enabled in kernel.
We care. Debugging output (extreme) vs no log (other extreme) are a total continuum. We want to know if hardware is misbehaving and for that dmesg is a friend we cannot lose. From docs, this is important to differenciate source of output in dmesg in multithread environements. This happens under Heads when generating gpg keys for example. Not sure we would want to loose possible tracing of users debugging traces.
Not sure if needed. I once had to create a x230 debugging config, needed to enable this along many other debugging options for dynamic debugging but that is corner case which might require documentation section instead of bloating kernel.
Definitely not needed. |
|
@Unb0rn I added two linux target helpers under tlaurion@dbe3fd3 I think it will be helpful in our quests of comparing different boards tweaked configurations between each other and quicken the development cycle in the future. In my branch, doing Creates /home/user/heads/build/x86/linux-5.10.5/linux-librem_common/.config from defconfig as explanations outputted in developer's terminal. Digging directly under /home/user/heads/build/x86/linux-5.10.5/linux-librem_common/.config shows us a lot of other things that could be tweaked, as said under #1184 including (strict example) AMD CPU options: Editing manually the oldefconfig file permits whole sections that can either be deactivated (OPTION=n) and passed to make BOARD=XYZ linux.menuconfig to save back into /home/user/heads/build/x86/linux-5.10.5/linux-librem_common/.config for manual verification until satisfaction. And then make BOARD=librem_15v4 linux.saveconfig can be used to save the file under savedefconfig format under git tree for verification. A quick play resulted into the following from my branch: And the following when compared to savedefconfig under master: |
|
Hi @Unb0rn, thank you for all the work on this so far! I generally agree that most of the suggested config changes make sense. I ran a few builds to check some of them to see how much space is actually saved. I can also help test other Librem devices when we have a CI build (I'll comment on the PR too regarding that). Overall it looks like we can save roughly 500KB which is pretty significant. I have notes about a few configs that we might want to keep or that I'm unsure of: |
|
Good news! Looks like all those changes (including "radical" ones like multiuser support) seem to work fine, flashrom works, kexec() boots, gpg signs and verifies, tpm works at least on Librem 14 |
|
That's great @Unb0rn! I have this on my to-do list to check some other devices. I have to cover a handful of other tasks first but I have not forgotten about this, thank you for all the work here! |
Is your feature request related to a problem? Please describe.
I'm trying to add BTRFS (will affect #1202) and exFAT filesystems support with the corresponding tools which means we'll need some space on flash to contain those. While digging the partial config (and comparing it to the full one after loading it) I found several options I'm not sure we want to have.
Describe the solution you'd like
So, those options found fall in several categories:
Debug/Verbosity:
Do we really need any of those in non-debug production setup?
Ancient/obsolete syscalls/features:
Do we have anything using these?
Unused features:
Support for systems it will never be run on:
I'm also not sure about these three:
Describe alternatives you've considered
Applied -Os patch from @tlaurion mentioned in #590
Additional context
Would be great to have any input about these parameters. If there is a chance any of them will make the system unusable it would be nice to know...
Also, maybe it's a good idea to enable discussions in project for questions like this? Issues don't really feel appropriate for it)
The text was updated successfully, but these errors were encountered: