From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932067AbbE1NRz (ORCPT <rfc822;w@1wt.eu>);
	Thu, 28 May 2015 09:17:55 -0400
Received: from mail-wg0-f47.google.com ([74.125.82.47]:36624 "EHLO
	mail-wg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751466AbbE1NRr (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 May 2015 09:17:47 -0400
Date: Thu, 28 May 2015 15:17:43 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@amacapital.net>,
        Peter Zijlstra <a.p.zijlstra@chello.nl>, mingo@elte.hu,
        Brian Gerst <brgerst@gmail.com>, fweisbec@gmail.com,
        tglx@linutronix.de, Linus Torvalds <torvalds@linux-foundation.org>,
        Denys Vlasenko <dvlasenk@redhat.com>,
        Josh Poimboeuf <jpoimboe@redhat.com>, linux-kernel@vger.kernel.org,
        hpa@zytor.com
Subject: Re: [PATCH] x86/debug: Remove perpetually broken, unmaintainable
 dwarf annotations
Message-ID: <20150528131743.GA9496@gmail.com>
References: <5566EBE7020000780007E659@mail.emea.novell.com>
 <20150528090133.GA469@gmail.com>
 <5566FFDD020000780007E711@mail.emea.novell.com>
 <20150528112017.GA28196@gmail.com>
 <55671D63020000780007E885@mail.emea.novell.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <55671D63020000780007E885@mail.emea.novell.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Jan Beulich <JBeulich@suse.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