On 8/27/2015 11:54 AM, Dan Williams wrote:
On Thu, Aug 27, 2015 at 8:35 AM, Linda Knippers
> On 8/27/2015 11:30 AM, Dan Williams wrote:
>> On Thu, Aug 27, 2015 at 7:43 AM, Linda Knippers <linda.knippers(a)hp.com>
>>> I don't see why we can't fix the names so they make sense now before
>>> 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
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.
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html