On 4 August 2016 at 02:30, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
> On 08/03/16 22:21, Anders Roxell wrote:
>
>> On 2 August 2016 at 17:27, Mike Holmes <mike.hol...@linaro.org> wrote:
>>
>>> On 2 August 2016 at 04:44, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
>>>
>>> On 08/02/16 10:54, Anders Roxell wrote:
>>>>
>>>> Signed-off-by: Anders Roxell <anders.rox...@linaro.org>
>>>>> ---
>>>>> helper/hashtable.c | 6 +++---
>>>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/helper/hashtable.c b/helper/hashtable.c
>>>>> index 8bb1ae5..f17b80f 100644
>>>>> --- a/helper/hashtable.c
>>>>> +++ b/helper/hashtable.c
>>>>> @@ -164,7 +164,7 @@ odph_table_t odph_hash_table_lookup(const char
>>>>> *name)
>>>>> * This hash algorithm is the most simple one, so we choose it as an
>>>>> DEMO
>>>>> * User can use any other algorithm, like CRC...
>>>>> */
>>>>> -uint16_t odp_key_hash(void *key, uint32_t key_size)
>>>>> +static uint16_t odp_key_hash(void *key, uint32_t key_size)
>>>>>
>>>>> odph_
>>>>
>>>> {
>>>>> register uint32_t hash = 0;
>>>>> uint32_t idx = (key_size == 0 ? 1 : key_size);
>>>>> @@ -181,7 +181,7 @@ uint16_t odp_key_hash(void *key, uint32_t key_size)
>>>>> /**
>>>>> * Get an available node from pool
>>>>> */
>>>>> -odph_hash_node *odp_hashnode_take(odph_table_t table)
>>>>> +static odph_hash_node *odp_hashnode_take(odph_table_t table)
>>>>> {
>>>>> odph_hash_table_imp *tbl = (odph_hash_table_imp *)table;
>>>>> uint32_t idx;
>>>>> @@ -208,7 +208,7 @@ odph_hash_node *odp_hashnode_take(odph_table_t
>>>>> table)
>>>>> /**
>>>>> * Release an node to the pool
>>>>> */
>>>>> -void odp_hashnode_give(odph_table_t table, odph_hash_node *node)
>>>>> +static void odp_hashnode_give(odph_table_t table, odph_hash_node
>>>>> *node)
>>>>>
>>>>>
>>>>> odph_
>>>>
>>>
>>> Should this patch change the name as well ?
>>>
>> I would say no. =)
>>
>> The fix appears to be to correctly make internal functions static whist
>>> converting to a naming scheme is a separate fix
>>>
>> agree.
>>
>> Cheers,
>> Anders
>>
>
> I don't mind if it will be 2 patches or 1 patch. If new issue was observed
> during review it has to be fixed with the same patch set.
> Or if you don't want/have time then you can file bug and we will take care
> about how will fix it.
>
> I would like to see one single patch here because you should not fix
> something partially and introduce patch lines with errors. If you
> touched that line than in my opinion it's logical to fix problem correct
> and completely. Problem from patch description is "to hide private
> functions".
>
Some times I agree that makes sense, but it is better to make a bug for a
second issue if a patch clearly fixes the issues it claims to, without a
balance we won't make progress if every patch requires fixing other issues
that are not directly implicated.
>
> regards,
> Maxim,
>
>
>
>>> {
>>>>
>>>>> odph_hash_table_imp *tbl = (odph_hash_table_imp *)table;
>>>>>
>>>>>
>>>>>
>>>>
>>> --
>>> Mike Holmes
>>> Technical Manager - Linaro Networking Group
>>> Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM
>>> SoCs
>>> "Work should be fun and collaborative, the rest follows"
>>>
>>
>
--
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
"Work should be fun and collaborative, the rest follows"
