Re: [PATCH 2/2]: acpica/nfit: Rename not-armed bit definition

From: Linda Knippers
Date: Thu Aug 27 2015 - 12:32:52 EST


On 8/27/2015 11:54 AM, Dan Williams wrote:
> On Thu, Aug 27, 2015 at 8:35 AM, Linda Knippers <linda.knippers@xxxxxx> wrote:
>> On 8/27/2015 11:30 AM, Dan Williams wrote:
>>> On Thu, Aug 27, 2015 at 7:43 AM, Linda Knippers <linda.knippers@xxxxxx> wrote:
>>>> I don't see why we can't fix the names so they make sense now before there
>>>> is hardware in the market. People doing testing and debugging look at stuff
>>>> in /sys and they write their own scripts too, not necessarily in python.
>>>
>>> The practical concern at this point is that it is too late in the 4.2
>>> development cycle, in my opinion, to push for a cosmetic change like
>>> this. We also have versions of libndctl starting to leak into
>>> distributions. Changing this in 4.3 means breaking the ABI from 4.2
>>> and managing both ways in future versions of the library as well as
>>> getting all distributions to update. Not insurmountable, but also
>>> something I don't want to take on just for a few characters in a sysfs
>>> file. I think this is better fixed with documentation which I still
>>> owe to the the Documentation/ABI/ directory.
>>
>> Is there any distribution that is going to enable this with 4.2? I know
>> we're using it for testing now but there is still quite a bit of work
>> queued up for 4.3 and more still left to be done.
>
> I'm not happy that this is confusing folks, and it is unfortunate that
> the polarity is reversed.
>
> However, I'm more concerned about the fact that I'd be knowingly
> breaking ABI from 4.2 to 4.3. I originally thought "no one" was using
> e820 type-12 for enumerating nvdimm resources, but I got shouted down
> when trying to convert that exclusively to the ACPI 6 definition. The
> Linus edict of "we don't break released ABI" is ringing in my ears.

Maybe not too late for 4.2 then. They're just string changes.

> The current name is also consistent with the current / released ACPICA
> definition.

They seem to be open to fixing it.

I know this seems like a nit but we've going to live with this stuff for
a long time.

-- ljk
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/