From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756974AbbE2RtN (ORCPT ); Fri, 29 May 2015 13:49:13 -0400 Received: from mail-la0-f41.google.com ([209.85.215.41]:34818 "EHLO mail-la0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756423AbbE2Rry (ORCPT ); Fri, 29 May 2015 13:47:54 -0400 MIME-Version: 1.0 In-Reply-To: <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> <20150528131743.GA9496@gmail.com> From: Andy Lutomirski Date: Fri, 29 May 2015 10:47:31 -0700 Message-ID: Subject: Re: [PATCH] x86/debug: Remove perpetually broken, unmaintainable dwarf annotations To: Ingo Molnar Cc: Jan Beulich , Borislav Petkov , Peter Zijlstra , Ingo Molnar , Brian Gerst , =?UTF-8?B?RnLDqWTDqXJpYyBXZWlzYmVja2Vy?= , Thomas Gleixner , Linus Torvalds , Denys Vlasenko , Josh Poimboeuf , "linux-kernel@vger.kernel.org" , "H. Peter Anvin" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 28, 2015 at 6:17 AM, Ingo Molnar wrote: > > * Jan Beulich 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. Before doing something drastic like this, I think we should get Josh's opinion, since I think he's working on a new (?) unwinder. FWIW, musl is considering some kind of automatic annotation scheme: http://www.openwall.com/lists/musl/2015/05/13/5 --Andy