On 03/26/2018 11:29 PM, Jon Maloy wrote:
>> Sorry, I don't suggest we should make so significant changes in order to
>> make function names better.
>>
>> If the changes are merged into upstream, it's almost impossible for
>> users to be able to easily back port TIPC patches from upstream version
>> to lower Linux version. Please remember there are many users who cannot
>> always upgrade kernel version again and again.
> Not sure what you are suggesting here. That I skip all name changes? That I 
> skip only the function and file name changes? That I skip the whole series?

Sorry for this confusion.

> 
> First, I believed you agreed that the change from an array structure to an RB 
> structure is a good thing. It solves two important problems which are not  
> about the code, but about architecture, regarding memory consumption and 
> table consistency. To me, this is a necessary and fundamental upgrade in 
> order to get rid of two old, lingering problems.

No, I don't objected to these changes. Instead, they are good things you
introduced in this series.

> 
> Assuming that this is not you concern, you should give some thought to what 
> the code will look like inside name_table.c after introduction of the tree 
> structure, with or without name changes. No patch made from name_table.c 
> after the structure change will be applicable on older Linux versions, in 
> either case. The changes are too fundamental. So we gain nothing by *not* 
> changing those struct and variable names there, either way.

Exactly! This is what I expect.

> 
> Regarding the parts visible outside name_table.c and name_distr.c I have some 
> more understanding for your concern, because those have impact on other files 
> (socket.c, node.c etc)
> 
> We could do as follows:
> Struct name_table ->  struct name_table  // I.e. no change. Visible 
> externally via name_table.h
> struct publication -> publication               // I.e., no change. Visible 
> externally and used by many other files.
> 
> struct name_seq -> struct tipc_service    // Only visible in name_table.c 
> anyway
> struct sub_seq -> struct service_range   // Only visible inside name_table.c
> struct publ_info   is removed, just as I do in the later commits
> 
> We don't change any externally visible function names or file names, unless 
> maybe when the functions anyway must be changed because of new/removed 
> parameters.
> This would fulfil my intention to make the code in name_table.c more readable 
> and up to common Linux standards, which I don't consider it to be now.
> 

Thanks, I agree with you.

> Regarding the changed API struct names in tipc.h in patch #2, I regard this 
> as important. The old names are meaningless to any new user, while the new 
> names give an immediate intuitive understanding of what they are, and are 
> consistent with how those are described in documentation and presentations. 
> And it is anyway a fully compatible and harmless change.

Yeah, we can change it.

Please go ahead with these changes.

Thanks,
Ying

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
tipc-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tipc-discussion

Reply via email to