Date: Sat, 09 Feb 2013 12:19:14 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Christoph Mallon <christoph.mallon@gmx.de> Cc: Kirk McKusick <mckusick@mckusick.com>, freebsd-arch@FreeBSD.org Subject: Re: Proposal: Unify printing the function name in panic messages() Message-ID: <511622A2.2090601@FreeBSD.org> In-Reply-To: <511616AC.8080306@gmx.de> References: <51141E33.4080103@gmx.de> <511426B8.2070800@FreeBSD.org> <51160E06.1070404@gmx.de> <5116121E.1010601@FreeBSD.org> <511616AC.8080306@gmx.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?511622A2.2090601>