[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150528131743.GA9496@gmail.com>
Date: Thu, 28 May 2015 15:17:43 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Jan Beulich <JBeulich@...e.com>
Cc: Borislav Petkov <bp@...en8.de>,
Andy Lutomirski <luto@...capital.net>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>, mingo@...e.hu,
Brian Gerst <brgerst@...il.com>, fweisbec@...il.com,
tglx@...utronix.de, Linus Torvalds <torvalds@...ux-foundation.org>,
Denys Vlasenko <dvlasenk@...hat.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
linux-kernel@...r.kernel.org, hpa@...or.com
Subject: Re: [PATCH] x86/debug: Remove perpetually broken, unmaintainable
dwarf annotations
* Jan Beulich <JBeulich@...e.com> wrote:
> > and meanwhile you can keep a revert of this patch ported to SUSE kernels in
> > whatever fashion you prefer.
>
> Funny suggestion - I don't think that's reasonable for us to do. Or if we were
> to, we could as well invest in doing the re-work you're asking for; I don't
> think anyone will have the time to do either.
That's fair enough: if there's not enough resources to keep a feature maintainable
upstream then it should not be upstream in that form.
This isn't just some driver we can let bit-rot in peace until it finds a
maintainer (or not), without affecting anyone but users of that driver.
This is hundreds of usage sites of ugly code intermixed with critical pieces of
assembly code that negatively affects the hackability of everything.
Also, with the feature missing completely, maybe someone finds a method to
introduce it in a maintainable fashion, while with the feature included upstream
there's very little pressure to do that. As a bonus we'd also win a workable dwarf
unwinder.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists