Messages in this thread | | | Date | Sun, 28 May 2017 11:11:28 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 00/21] liblockdep fixes for v4.12 |
| |
* Levin, Alexander (Sasha Levin) <alexander.levin@verizon.com> wrote:
> On Fri, May 26, 2017 at 01:21:51PM +0200, Ingo Molnar wrote: > > > > * Levin, Alexander (Sasha Levin) <alexander.levin@verizon.com> wrote: > > > > > Right, and as you can see from this patchset where we added to > > > tools/include/ when needed and removed from lib/lockdep/uinclude, > > > liblockdep is slowly creeping the "right" way. > > > > > > perf, like liblockdep, didn't finish the switch to exclusively use > > > tools/include/ yet. > > > > > > I can put more work into getting it done over the next few releases, > > > but it's not something I see as a critical fix for the upcoming > > > release. > > > > Since liblockdep was broken for an extended period of time I'd really > > like to see this fixed before I apply any more patches. > > What does the build breakage has to do with converting the way we use headers? > There's no broken functionality as far as I can tell, so why is the header thing > defined as a "fix" to begin with?
liblockdep was essentially build-broken for almost a year.
I worry about and question liblockdep's general maintainability and as a maintainer of lockdep I can see only two options going forward: either it's cleaned up for good (going beyond what is needed to fix the build failures and warnings), or we remove it (with the option of reintroducing it if/when it's clean enough).
I.e. the quality bar has increased.
> I also don't see a single tools/ project to exclusively use tools/include at > this point. > > Would you rather keep liblockdep broken for the next couple of months until this > is sorted? I really doubt I could get something (+ enough time to soak in -next) > for v4.13, so we're looking at v4.14 at the earliest.
No, if it does not improve then I'd rather remove it, and re-add it at a later date if/when it's clean enough.
Thanks,
Ingo
| |