* Levin, Alexander (Sasha Levin) <[email protected]> wrote:
> On Fri, May 26, 2017 at 01:21:51PM +0200, Ingo Molnar wrote: > > > > * Levin, Alexander (Sasha Levin) <[email protected]> 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
