lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <560AD8E5.1000001@linux.vnet.ibm.com>
Date:	Wed, 30 Sep 2015 00:01:01 +0530
From:	Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
To:	Nishanth Aravamudan <nacc@...ux.vnet.ibm.com>
CC:	benh@...nel.crashing.org, paulus@...ba.org, mpe@...erman.id.au,
	anton@...ba.org, linuxppc-dev@...ts.ozlabs.org,
	linux-kernel@...r.kernel.org, cl@...ux.com,
	gkurz@...ux.vnet.ibm.com, grant.likely@...aro.org,
	nikunj@...ux.vnet.ibm.com, khandual@...ux.vnet.ibm.com
Subject: Re: [PATCH RFC  2/5] powerpc:numa Rename functions referring to nid
 as chipid

On 09/28/2015 10:57 PM, Nishanth Aravamudan wrote:
> On 27.09.2015 [23:59:10 +0530], Raghavendra K T wrote:
>> There is no change in the fuctionality
>>
>> Signed-off-by: Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
>> ---
>>   arch/powerpc/mm/numa.c | 42 +++++++++++++++++++++---------------------
>>   1 file changed, 21 insertions(+), 21 deletions(-)
>>
>> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
>> index d5e6eee..f84ed2f 100644
>> --- a/arch/powerpc/mm/numa.c
>> +++ b/arch/powerpc/mm/numa.c
>> @@ -235,47 +235,47 @@ static void initialize_distance_lookup_table(int nid,
>>   	}
>>   }
>>
>> -/* Returns nid in the range [0..MAX_NUMNODES-1], or -1 if no useful numa
>> +/* Returns chipid in the range [0..MAX_NUMNODES-1], or -1 if no useful numa
>>    * info is found.
>>    */
>> -static int associativity_to_nid(const __be32 *associativity)
>> +static int associativity_to_chipid(const __be32 *associativity)
>
> This is confusing to me. This function is also used by the DLPAR code
> under PowerVM to indicate what node the CPU is on -- not a chip (which I
> don't believe is exposed at all under PowerVM).
>

Good point.

should I retain the name nid?
or any suggestions? instead of chipid -> nid which fits both the cases.
or should I rename like nid->vnid  something?
[...]
>> @@ -1415,7 +1415,7 @@ int arch_update_cpu_topology(void)
>>
>>   		/* Use associativity from first thread for all siblings */
>>   		vphn_get_associativity(cpu, associativity);
>> -		new_nid = associativity_to_nid(associativity);
>> +		new_nid = associativity_to_chipid(associativity);
>
> If you are getting a chipid, shouldn't you be assigning it to a variable
> called 'new_chipid'?

yes perhaps.
my splitting idea was
1. change nid name in functions to chipid (without changing nid
variable calling that function)
2. rename variables to chipid and assign nid=chipid (1:1 mapping)
3. now let nid = mapped chipid

But I see that it isn't consistent in some places. do you think
merging step 1 and step 2 is okay?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ