Hi, Leo Famulari <l...@famulari.name> writes:
> On Fri, Jul 04, 2025 at 10:05:49PM +0900, Maxim Cournoyer wrote: >> For reducing the maintenance churn, it seems we should only version a >> defconfig. That has the merit of showing only how our configuration >> differs from that of the kernel defaults, which is in my opinion what is >> interesting. >> >> I'd expect the .defconfig to rarely have to change, instead of the churn >> of the .config containing every new option having to be generated for >> each kernel. > > I think it's an interesting idea to store the defconfig because it shows > the salient differences, as you point out. > > Currently, it's nice to have the full kernel configurations stored in > Git, because we can easily refer to them. > > Otherwise, they'd be generated dynamically during building and that is > less convenient for analysis. We could keep both, as was suggested by Tobias in the past, but my point was that by keeping the defconfig, it shouldn't need changing all the time unless we keep choosing values at odd with the upstream defaults. > Of course, this already happens partially, because the configuration > options change with every minor release, but typically we only create a > config file once per major release. So almost every build has some > dynamic configuration where the defaults are chosen. For old kernels > like 5.4, a lot of options are decided automatically. > > So I think that in the context of understanding the configurations, it's > a mixed bag. No gain or loss with your suggestion IMO. > > With each kernel release, we'd still have to evaluate every new or > changed kernel option, in order to decide if we want to use the default > or not, so I think the amount of work performed by people would remain > the same. Unless I misunderstand the suggestion. I'd think evaluating every new or changed kernel option is a nice to have rather than a requirement. The kernel is very strict at changing or adding new defaults, so I wouldn't see it unreasonable to simply trust the default configuration as sane. So we'd have a .defconfig file which lists just what we chose differently from upstream Linux, and every kernel bump would be a matter of updating its hash, and rarely, perhaps enabling something not in the default config, which would be added to our defconfig file. Does that sound easier to handle? -- Thanks, Maxim
