From owner-freebsd-arch@FreeBSD.ORG Tue Feb 12 01:34:43 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 45DFDA73; Tue, 12 Feb 2013 01:34:43 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) by mx1.freebsd.org (Postfix) with ESMTP id 1EB7EB27; Tue, 12 Feb 2013 01:34:43 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id r1C1Ycfh026347; Mon, 11 Feb 2013 17:34:39 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201302120134.r1C1Ycfh026347@chez.mckusick.com> To: John Baldwin Subject: Re: Proposal: Unify printing the function name in panic messages() In-reply-to: Date: Mon, 11 Feb 2013 17:34:38 -0800 From: Kirk McKusick X-Spam-Status: No, score=0.0 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on chez.mckusick.com 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 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 01:34:43 -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. Kirk McKusick