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