From owner-freebsd-arch@FreeBSD.ORG Sat Feb 9 10:19:19 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 057F4576 for ; Sat, 9 Feb 2013 10:19:19 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3109720A for ; Sat, 9 Feb 2013 10:19:17 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA19800; Sat, 09 Feb 2013 12:19:15 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1U47Wd-0007nt-Jl; Sat, 09 Feb 2013 12:19:15 +0200 Message-ID: <511622A2.2090601@FreeBSD.org> Date: Sat, 09 Feb 2013 12:19:14 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: Christoph Mallon Subject: Re: Proposal: Unify printing the function name in panic messages() References: <51141E33.4080103@gmx.de> <511426B8.2070800@FreeBSD.org> <51160E06.1070404@gmx.de> <5116121E.1010601@FreeBSD.org> <511616AC.8080306@gmx.de> In-Reply-To: <511616AC.8080306@gmx.de> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kirk McKusick , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 10:19:19 -0000 on 09/02/2013 11:28 Christoph Mallon said the following: > On 09.02.2013 10:08, Andriy Gapon wrote: >> In any case, you just search the code for the message and that's it. > > Often the messages contains parameters (%d, %s, ...) or are split into multiple lines to appease the ancient 80 columns god. > These make it harder to grep. > Having the /right/ name makes it easier to get to the right place. Having right tools for the search does that too. And doesn't require any code churn. >> If this is a solution in search of a problem, then I don't like it, because it > > The two problems this change solves are very simple: > - There are needlessly about a dozen different ways used to add the function name into the panic message. > This change unifies it. > - All too often the name is wrong. > This change gets it right every time without any manual and error-prone effort of somebody, who adds a use of PANIC(). There is no need to have a function name in panic message. If it's present and if it's incorrect - these are very minor details. We are not talking about new code that prevents real bugs. >> requires massive, if mostly mechanical, changes throughout the code. > > I do not understand, what the problem is. > There are bugs and cumbersome code. > This simple changes solves it. You conveniently omitted some questions of mine. I'll reproduce them: Well, have you experienced any problems with debugging due to those (absent/misleading) function names? Or do you see many reports about such problems? So I conclude that this is indeed a solution in search of a problem. And that's exactly why i don't like it: - a lot of lines changed for no good reason - code looks uglier / more obfuscated due to macro(s) - no clear benefit, because there is no clear problem that needs solving -- Andriy Gapon