On 12/06/2016 04:44 AM, Thorsten Leemhuis wrote: > Lo! On 21.11.2016 19:46, Laura Abbott wrote: >> >> As a follow up to the previous discussion about kernel configuration >> in Fedora (https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx/thread/DBOBI6F3SLEAW2O5RLGZOOXQ5VKEWQIW/) >> I have a prototype of what a method of keeping each configuration >> file in a separate file would look like. This method takes care of >> several of my gripes of the current version (and found a few errors >> in the existing config files). The biggest question I have is if >> this will scale for how frequently Fedora adjusts configuration >> options. Some of that could possibly be solved with more scripting >> improvements. >> >> The repo is at https://pagure.io/fedora-kernel-labbott/branch/split_configs > > I took a brief look. Overall I thought "if it makes maintaining the > configs easier, go ahead, I don't care much". There are just a few > things I noticed while looking at it: > > * nitpicking: I found the filenames "generate_(all|debug)_configs.sh" > misleading, because those scripts do not generate a config, as they > afaics just put a pre-generated config in place so they are going to be > used. > > * I really like that this finally gets rids of the noise in the config > file diffs that the frequent enabling/disabling using "make > (debug|release)" creates currently. > > * Just thinking aloud: I wonder if the pre-generated *debug.configs are > a good idea. Wouldn't it be more obvious what is happening if we'd ship > one base config (e.g. where debugging is turned off) and then have > something in the spec file itself that builds slightly modified version > depending on what is needed in the current build? Having a mechanism > like this might be handy for other situations as well. For example we > could have something in the spec file that automatically disables > "CONFIG_ARM64_VA_BITS_48" and "CONFIG_ARM64_VA_BITS" when building for > "$fedora_release <= F25"; this way we'd make sure things like that do > not accidental make it into older releases during a rebase. I'm not sure how that would be more obvious. Generating the configs makes it easier to check each file to see what's present vs not being able to see what's enabled until it is built. I'm wary to put anything more in the .spec file than we have to since the file is complicated enough as is. Having the spec file enforce config policy would be a step in the wrong direction. Thanks, Laura > > HTH, CU, knurd > _______________________________________________ > kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
