From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752054AbbE0GLt (ORCPT ); Wed, 27 May 2015 02:11:49 -0400 Received: from mail-pd0-f175.google.com ([209.85.192.175]:36278 "EHLO mail-pd0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751398AbbE0GLs (ORCPT ); Wed, 27 May 2015 02:11:48 -0400 Date: Wed, 27 May 2015 15:12:10 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Sergey Senozhatsky , Sergey Senozhatsky , Andrew Morton , Marcin Jabrzyk , Nitin Gupta , linux-kernel@vger.kernel.org Subject: Re: [PATCH] zram: check comp algorithm availability earlier Message-ID: <20150527061210.GB3928@swordfish> References: <1432646017-1367-1-git-send-email-sergey.senozhatsky@gmail.com> <20150527035142.GA11609@blaptop> <20150527055320.GA3928@swordfish> <20150527055854.GE11609@blaptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150527055854.GE11609@blaptop> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (05/27/15 14:58), Minchan Kim wrote: > > > I'm not against this patch because it's better than old. > > > But let's think more about the pr_err part. > > > > > > If user try to set wrong algo name, he can see EINVAL. > > > Isn't it enough? > > > > > > I think every sane admin can think he passed wrong argument > > > if he sees -EINVAL. > > > So, I don't think we need to emit pr_err in here. > > > > > > > well, it's here simply to make failure investigation easier. > > one surely will know that supplied string was not recognized > > as a compression algorithm name, but what was it.. "$3 instead > > of $2... or, wait, did $i contain something wrong?". zram knew > > what was wrong. > > > > /* and you asked to put this warn here in your previous email. */ > > Yes, Sorry about that. At that time, you put the warning in find_backend > and I didn't like it. Instead, I want to move it to in there. > But more thinking about it, I don't feel we need it. > no problem. > > > The reason I am paranoid about that is that I really don't want > > > to argue with syslog info which is part of ABI or not in future. > > > If possible, I don't want to depend on pr_xxx. > > > > > > > just for the record... I don't understand this part. > > I meant if we remove the pr_err in future by some reason, > someone might shout > > "No, it's ABI so if you guys removes it, it will break user interface's > semantic". Maybe he seems to depends on parse on dmesg. > ah, I see. well, hopefully no one does this. anyway, will remove it. hm, I was thinking about some sort of a troubleshooting section in zram documentation, where we can `decrypt' some of the errors that we return back. but still did not convince myself that it will be of any use, just doubt that people read documentation that often. speaking of docs, mentioning zramctl in zram docs is actully not entirely bad idea, I think. zramctl has been in util-linux for (almost) a year now and sooner or later will be widely available. -ss