From owner-freebsd-arch@FreeBSD.ORG Tue Feb 12 03:56:52 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 116A3CE4; Tue, 12 Feb 2013 03:56:52 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [IPv6:2001:470:c004::5]) by mx1.freebsd.org (Postfix) with ESMTP id C3240B8; Tue, 12 Feb 2013 03:56:51 +0000 (UTC) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.14.5/8.14.5) with ESMTP id r1C3W9i3005646; Mon, 11 Feb 2013 21:32:09 -0600 (CST) (envelope-from mike@karels.net) Message-Id: <201302120332.r1C3W9i3005646@mail.karels.net> To: Kirk McKusick From: Mike Karels Subject: Re: Proposal: Unify printing the function name in panic messages() In-reply-to: Your message of Mon, 11 Feb 2013 17:34:38 -0800. <201302120134.r1C1Ycfh026347@chez.mckusick.com> Date: Mon, 11 Feb 2013 21:32:09 -0600 Cc: Adrian Chadd , Christoph Mallon , Andriy Gapon , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mike@karels.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 03:56:52 -0000 > I have recently gone down several ratholes trying to understand a > panic message which had the wrong function name (prefix ufs1_ instead > of ufs2_). I can definitely say that it matters to me. And I think > that fixing the problem as Christoph has outlined will be a big > step in the right direction. > John, in your code you cannot expect to match the entire panic > string if it has any % formats in it. So to be useful, you must be > able to work with a constant subset of the string. The addition of > other information such as a function name at the start should not > affect that constant part that you are trying to match. > Though a bit ugly, I do think that the change should use "PANIC" > rather than overloading "panic". First, it lets the feature be > introduced over time rather than requiring that every panic be > changed at once. And, it allows historic panic's to work as expected. > Finally, having it as a macro means that folks can readily and > consistently add file and/or line numbers to panic messages if they > wish to do so. > Summary: I think that this is an excellent idea that will both help > in finding the location of panic errors and also will allow folks > trying to minimize kernel size to do so by cutting out the overhead. I don't think that the proposal is to introduce this feature over time, but instead to mechanically change as many instances as possible. However, if I understand correctly, that would include primarily the instances now using the function name "correctly", not those using the wrong function name. I really don't want to see the kernel half-converted from panic() to PANIC(). I'd rather see lower-case panic as an available macro depending on a kernel option. However, as John notes, this option is of reduced utility if it isn't on by default, and I don't see sufficient reason to turn it on by default. Perhaps I haven't spent as much time looking at the wrong function for panics that have been cloned badly, but I tend to use glimpse if I don't know where the panic is coming from. It seems to me that a script looking for duplicate panic strings would solve the real problem much more quickly. Mike