Messages in this thread | | | Date | Mon, 10 Oct 2022 08:42:41 +0100 | From | Lee Jones <> | Subject | Re: [GIT PULL] Backlight for v6.1 |
| |
On Fri, 07 Oct 2022, Linus Torvalds wrote:
> On Fri, Oct 7, 2022 at 6:16 AM Lee Jones <lee@kernel.org> wrote: > > > > PR satisfying this dependency was submitted the following day: > > .. you ignored the whole "another driver hit v6.0 without ever getting > the dependency".
Not ignored. I provided you with a response applicable to the situation surrounding *this* pull-request. As for the actions / motives of other maintainers, I cannot / should not comment.
Admittedly, that is not to say this could not have happened solely between 2 subsystems that I maintain! The other subsystem maintainers and I work together regularly, utilising immutable branches to ensure we do not cause build breakage at merge-time, but we (clearly) do not work to the same levels of due diligence with respect to dependencies preventing full build test / coverage.
> In particular, there was a silent semantic conflict in the Crystal > Cove (intel PMIC) driver with the i2c changes. I noticed it because > there were other things going on, and I went and looked.
It appears as though, Andy, Hans and yourself are having a nice conversation about this particular instance already - I'll leave you to it.
> So I caught this particular issue, but I really think that code that > cannot be enabled at all even for build testing - or code that is > quite hard to enable either intentionally or by mistake - is a > problem.
Unbuildable / untestable code is an interesting problem. One which, I must say, I haven't taken a particularly deep look into. Even though MFDs (and their associated children) are particularly susceptible to dependency issues that would otherwise prevent testing, I very much doubt this problem is unique to MFD.
To your knowledge, has there been any research into unbuildable drivers (/ subsystems!)? There must have been some notable studies on (static / running) code coverage analysis, but I'd be surprised if these cover code that simply cannot be built / executed.
Until this point, I assumed my build-coverage was rather good. It covers varying compilers, 7 architectures, and many different *_defconfigs which include allmodconfig and allyesconfig, totalling 70 unique kernel builds.
You have been mentioning allmodconfig a fair bit. Are you also including allyesconfig in your observations? Does that not alleviate some of the angst around what should be built-in vs modules in terms of buildability?
If this is as big of an issue as you say, perhaps we should invest a little time to investigate some sound method(s) to scan for similar instances. Tricky to do, seeing how many different architectures / platforms the kernel supports.
-- Lee Jones [李琼斯]
| |