[lkml]   [2014]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH] memory driver: make phys_index/end_phys_index reflect the start/end section number
On 04/08/2014 02:47 PM, Dave Hansen wrote:
> On 04/08/2014 11:23 AM, Nathan Fontenot wrote:
>> On 04/08/2014 11:13 AM, Dave Hansen wrote:
>>> On 04/08/2014 01:27 AM, Li Zhong wrote:
>>>> If Dave and others don't have further objections, it seems this small
>>>> userspace incompatibility could be accepted by most of us, and I don't
>>>> need to make a version 2.
>>> Let me ask another question then. What are the units of
>>> phys_index/end_phys_index? How do we expose those units to userspace?
>> The documentation for these files just states that the files contain
>> the first and last section id of memory in the memory block for
>> phys_index and end_phys_index respectively.
>> I'm not sure the values have ever been units of anything, at least not
>> that I remember.
> <sigh>
> There are two units. SECTION_SIZE, which is completely internal to the
> kernel, and block_size_bytes which used to be the same as SECTION_SIZE,
> but is not now. Which one of those two is phys_index/end_phys_index in,
> and if it is in terms of SECTION_SIZE like this patch proposes, how do
> we tell userspace how large SECTION_SIZE is?
> block_size_bytes is supposed to tell you how large the sections are. In
> the case where we lumped a bunch of sections together, we also bumped up
> block_size_bytes. That's why we currently divide the *ACTUAL* section
> number in phys_index/end_phys_index by block_size_bytes.
> That document really needs to be updated to stop referring to sections
> (at least in the descriptions of the user interface). We can not change
> the units of phys_index/end_phys_index without also changing
> block_size_bytes.

Re-reading the documentation. You're correct, it needs help.


 \ /
  Last update: 2014-04-10 08:01    [W:0.075 / U:43.032 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site