Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756588AbbHGHZH (ORCPT ); Fri, 7 Aug 2015 03:25:07 -0400 Received: from mail-pa0-f49.google.com ([209.85.220.49]:32988 "EHLO mail-pa0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756199AbbHGHZD (ORCPT ); Fri, 7 Aug 2015 03:25:03 -0400 Date: Fri, 7 Aug 2015 16:25:37 +0900 From: Sergey Senozhatsky To: Joe Perches Cc: Sergey Senozhatsky , Minchan Kim , Salah Triki , ngupta@vflare.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/3] zram: Replace pr_* with dev_* Message-ID: <20150807072537.GJ1891@swordfish> References: <20150807000520.GA1891@swordfish> <20150807060559.GA7716@bgram> <20150807063756.GH1891@swordfish> <20150807065611.GI1891@swordfish> <1438931526.2322.14.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1438931526.2322.14.camel@perches.com> User-Agent: Mutt/1.5.23+102 (2ca89bed6448) (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1489 Lines: 44 On (08/07/15 00:12), Joe Perches wrote: > On Fri, 2015-08-07 at 15:56 +0900, Sergey Senozhatsky wrote: > > On (08/07/15 15:37), Sergey Senozhatsky wrote: > > [..] > > where we had clean and nice > > > > pr_err("Decompression failed!... > > pr_info("Unable to allocate temp memory\n"... > > etc... > > > > now we have monsters > > > > dev_err(disk_to_dev(zram->disk), "Decompression failed!... > > dev_info(disk_to_dev(zram->disk), "Unable to allocate temp memory\n"... > > etc. > [] > > other changes are very questionable... for example > > pr_info("Added device: %s\n", zram->disk->disk_name); > > becomes > > dev_info(disk_to_dev(zram->disk), "Added device: %s\n", zram->disk->disk_name); > > > > why? there is no reason to do this! > > This seems a reasonable complaint. > > One option is to add some macros like > > #define zram_err(zram, fmt, ...) \ > dev_err(disk_to_dev((zram)->disk), fmt, ##__VA_ARGS__) > > But the overall utility of the proposed changes is > moderately low to non-existent. yes, sure. but we still need to change several internal functions to start accepting struct zram pointer just to be able to show extra prefix in error messages (if we want the messages to be more or less consistent). -ss -- 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/