On Wed, 18 Dec 2019 20:01:55 +0100, Pierre-Louis Bossart wrote: > > > > >>>>> Then the issue I pointed above can be solved as well. > >>>> > >>>> The ifdefs are still needed in the PCI IDs tables > >>> > >>> Yes, but it halves the messes :) > >> > >> I wish it was true :-) > >> > >> In reality having buildbots play with kconfig options does help > >> identify issues at the code level, just like the namespace use helped > >> identify the .arch_ops just above did not belong here. > >> I find it's a constant battle to avoid accumulated crud in the wrong > >> places when dealing with multiple platforms, and when looking at > >> patches it's very hard (at least for me) to realize where the code > >> gets added and the implications. > > > > But how it can be worse than ifdef...? From the resultant code POV, > > it's same, the redundant objects are dropped automatically, while you > > can avoid a pitfall like this case to forget the counter-part ifdef, > > which could be identified at first by some randconfig tests. > > In a perfect world it'd be fine. > But the reviews are not perfect and it happens that we let things go > through. > With the _maybe_unused proposal, I would not know which objects are > not necessary for a specific config, they would be silently removed by > a tool. Issues reported by randconfig or 'unused variable' warnings > are painful but at least they do provide a clear hint that something's > not right (including in my own code). Well, it's another side of coin. With the current massive Kconfig and ifdef, something can be overlooked pretty easily. A randconfig may catch it up, but this would be often after the commit. But it's basically just a minor bikeshed thing. However, the main concern is: unless Intel stops producing a newer model, we'll go soon beyond the amount of Kconfigs we can manage manually. Usually splitting Kconfig items makes sense if - - Functionality needs to be selective, - It reduces the resultant code significantly, or - Modules to be built can be chosen (and reduces memory footprint) When looking at the current code, for example, I'm not sure which category hits the case of Cometlake-S vs Cometlake-H vs Cometlake-LP... In short: I'd love to see if Kconfigs can be reduced as much as possible. It'll make our life easier for users, including distros, in the end. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
