Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752673AbbHZT7P (ORCPT ); Wed, 26 Aug 2015 15:59:15 -0400 Received: from g4t3425.houston.hp.com ([15.201.208.53]:46657 "EHLO g4t3425.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751788AbbHZT7N (ORCPT ); Wed, 26 Aug 2015 15:59:13 -0400 Subject: Re: [PATCH 2/2]: acpica/nfit: Rename not-armed bit definition To: Dan Williams , Toshi Kani References: <1440606024-29873-1-git-send-email-toshi.kani@hp.com> <1440606024-29873-3-git-send-email-toshi.kani@hp.com> Cc: "linux-nvdimm@lists.01.org" , Rafael J Wysocki , Robert Moore , "linux-kernel@vger.kernel.org" , Linux ACPI From: Linda Knippers X-Enigmail-Draft-Status: N1110 Message-ID: <55DE1A8E.9000303@hp.com> Date: Wed, 26 Aug 2015 15:59:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2317 Lines: 56 On 8/26/2015 1:16 PM, Dan Williams wrote: > On Wed, Aug 26, 2015 at 9:20 AM, Toshi Kani wrote: >> ACPI 6.0 NFIT Memory Device State Flags in Table 5-129 defines >> bit 3 as follows. >> >> Bit [3] set to 1 to indicate that the Memory Device is observed >> to be not armed prior to OSPM hand off. A Memory Device is >> considered armed if it is able to accept persistent writes. >> >> This bit is currently defined as ACPI_NFIT_MEM_ARMED, which can be >> confusing as if the Memory Device is armed when this bit is set. >> >> Change the name to ACPI_NFIT_MEM_NOT_ARMED per the spec. >> >> Signed-off-by: Toshi Kani >> Cc: Dan Williams >> Cc: Bob Moore >> Cc: Rafael J. Wysocki >> --- >> drivers/acpi/nfit.c | 6 +++--- >> drivers/acpi/nfit.h | 2 +- >> include/acpi/actbl1.h | 2 +- > > This file "include/acpi/actbl1.h" is owned by the ACPICA project so > any changes need to come through them. But that said, I'm not sure we > need friendly names at this level. > > What I usually say about sysfs name changes to be more human friendly > is "sysfs is not a UI", i.e. it's not necessarily meant to be user > friendly. As long as the names for the flags are distinct then > wrapping descriptive / accurate names around them is the role of > libndctl and userspace management software. I think there's a difference between unfriendly and misleading or confusing. If names didn't matter at all we could just call them bit0, bit1, bit2,... > Similar feedback for patch1 in the sense that I don't think we need to > update the sysfs naming. For example the API to retrieve the state of > the "arm" flag in libndctl is ndctl_dimm_failed_arm(). It would be so nice for scripts and humans if the sysfs names made as much sense. -- ljk > _______________________________________________ > Linux-nvdimm mailing list > Linux-nvdimm@lists.01.org > https://lists.01.org/mailman/listinfo/linux-nvdimm > -- 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/