This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Wed May 8 14:19:47 2024 Received: from vger.kernel.org (vger.kernel.org [209.116.70.75]) by kylie.puddingonline.com (8.11.6/8.11.6) with ESMTP id g8O4xFX12934 for ; Tue, 24 Sep 2002 06:59:15 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 24 Sep 2002 00:52:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 24 Sep 2002 00:52:18 -0400 Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:26890 "EHLO www.linux.org.uk") by vger.kernel.org with ESMTP id ; Tue, 24 Sep 2002 00:52:17 -0400 Received: from c-24-98-61-134.atl.client2.attbi.com ([24.98.61.134] helo=pobox.com) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 17thlJ-00055u-00 for linux-kernel@vger.kernel.org; Tue, 24 Sep 2002 05:57:29 +0100 Message-Id: <3D8FF09A.9070502@pobox.com> Date: Tue, 24 Sep 2002 00:56:58 -0400 From: Jeff Garzik Organization: MandrakeSoft User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en Mime-Version: 1.0 To: Linux Kernel Mailing List Subject: Re: [PATCH-RFC] README 1ST - New problem logging macros (2.5.38) Content-Type: multipart/mixed; boundary="------------030000030007060200080309" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org This is a multi-part message in MIME format. --------------030000030007060200080309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------030000030007060200080309 Content-Type: message/rfc822; name="Re: [PATCH-RFC] README 1ST - New problem logging macros (2.5.38)" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: [PATCH-RFC] README 1ST - New problem logging macros (2.5.38)" Message-ID: <3D8FF040.2040905@pobox.com> Date: Tue, 24 Sep 2002 00:55:28 -0400 From: Jeff Garzik Organization: MandrakeSoft User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Larry Kessler CC: Alan Cox , Rusty Russell , linux-kernel@us.ibm.com, mailing@us.ibm.com, list@us.ibm.com Subject: Re: [PATCH-RFC] README 1ST - New problem logging macros (2.5.38) References: <3D8FC601.80BAC684@us.ibm.com> <3D8FD0A9.1010906@pobox.com> <3D8FE876.EC1B050C@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Larry Kessler wrote: > Jeff Garzik wrote: > >>> } >>> if (!request_mem_region(pci_resource_start(pdev, 0), >>> pci_resource_len(pdev, 0), "eepro100")) { >>>- printk (KERN_ERR "eepro100: cannot reserve MMIO region\n"); >>>+ pci_problem(LOG_ERR, pdev, "eepro100: cannot reserve MMIO region"); >> >>bloat, no advantage over printk > > > the advantage is that the string, which means plenty to the developer, but possibly > much less to a Sys Admin, can be replaced with a more descriptive message, > in the local language, by editing the formatting template in user-space. So, a static string passed to printk can't be translated, but a static string passed to pci_problem() can? And in your view is it impossible to deduce a format string from the current code? > > >>> if (sum != 0xBABA) >>>- printk(KERN_WARNING "%s: Invalid EEPROM checksum %#4.4x, " >>>- "check settings before activating this device!\n", >>>- dev->name, sum); >>>+ net_pci_problem(LOG_WARNING, dev, pdev, "Invalid EEPROM checksum, " >>>+ "check settings before activating this device!", >> >>>+ detail(checksum, "%#4.4x", sum)); >> >>bloat, checksum is purely informational, and can be obtained through >>other means > > > indeed. See previous comment. indeed :) And for thinking outside the box, here's a random idea: when CONFIG_EVLOG is defined, printk() turns into a tagged format that spits out its format string, then a list of variable names and values. Given some C and cpp magic, that should be possible with no code changes at all to drivers. An overriding objection to all this need of information. It is so wrong to decide to just continuing dump all information available, and hope that it will become useful. Decide which information is useful first... Do you guys even have an idea what diagnostic info is useful from network drivers? from SCSI drivers? If yes, speak up. I would love to improve the diagnostics of my net drivers where possible. If not... please figure out the problem before implementing a solution. Jeff --------------030000030007060200080309-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/