Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752993AbbDLVhZ (ORCPT ); Sun, 12 Apr 2015 17:37:25 -0400 Received: from a.ns.miles-group.at ([95.130.255.143]:65275 "EHLO radon.swed.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752174AbbDLVhY (ORCPT ); Sun, 12 Apr 2015 17:37:24 -0400 Message-ID: <552AE592.5000609@nod.at> Date: Sun, 12 Apr 2015 23:37:22 +0200 From: Richard Weinberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Boris Brezillon CC: Andrea Scian , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, dedekind1@gmail.com Subject: Re: [PATCH 4/4] UBI: Implement bitrot checking (linux-mtd Digest, Vol 145, Issue 24) References: <552AA390.3070700@nod.at> <552AD8A6.6000406@dave-tech.it> <552ADD27.6080703@nod.at> <20150412233019.2b4eac3e@bbrezillon> In-Reply-To: <20150412233019.2b4eac3e@bbrezillon> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1615 Lines: 41 Am 12.04.2015 um 23:30 schrieb Boris Brezillon: > On Sun, 12 Apr 2015 23:01:27 +0200 > Richard Weinberger wrote: > > >>>>>>>> +static struct device_attribute dev_trigger_bitrot_check = >>>>>>>> + __ATTR(trigger_bitrot_check, S_IWUSR, NULL, trigger_bitrot_check); >>>>>>> >>>>>>> How about making this attribute a RW one, so that users could check >>>>>>> if there's a bitrot check in progress. >>>>>> >>>>>> As the check will be initiated only by userspace and writing to the trigger >>>>>> while a check is running will return anyway a EBUSY I don't really see >>>>>> a point why userspace would check for it. >>>>> >>>>> Sometime you just want to know whether something is running or not (in >>>>> this case the bitrot check) without risking to trigger a new action... >>>> >>>> Why would they care? >>> >>> I think is always useful to give some additional information in userspace, from both debugging and diagnostic point of view. >> >> The question is, why does userspace care? >> Other UBI operations are also not visible... > > Yes, but AFAIK other wear-leveling operations are not directly triggered > by user-space. If userspace trigger is, it knows that it was triggered. Unless you have multiple tools/scripts which want to trigger it, which is IMHO a problem anyways. But as stated before, I can add an indicator. Thanks, //richard -- 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/