[cgl_discussion] v2.5 TIPC TODO list

Jon Maloy jon.maloy at ericsson.com
Thu Mar 13 12:19:44 PST 2003


Se my comments below.
 I would love to go in and do some of this myself (at least I
would have it my way...), but I don't  have time  for that in
the near future.

Regards /Jon


Mika Kukkonen wrote:

>These are the "janitoring" items mentioned in PoC that I would be 
>grateful if somebody would look into, listed in some order of
>preference (remember, I am talking about my code, not Jon's):
>
>	0) Currently message sending does not work
>		- probably macro issue
>	        - Mark is looking into this
>
>	1) Spurious printk's to the console:
>             - bloody annoying
>	     - fix is to replace every printf* from the code
>	       with the err(), warn(), info(), and dbg()
>
This will fix the different printout functions to a certain "debug level".
Probably ok, since this is the way they are used anyway, and I was never
happy with printf0(), printf1() etc in the first place. But keep the
target macros !

>	     - Mark is planning to look into this too, so
>	       talk with him first
>
>	2) Decoupling of dbg_buf, stats_buf and shutting down
>	   the raw bearers:
>	     - currently if you turn off TIPC_DBG_BUF you lose
>	       statistics and more importantly shutting down
>	       the raw bearers
>	     - I have my doubts about the usability of the whole
>	       dbg_buf concept, but at least currently plan is not
>	       to diverge on functionality, so it should stay
>
Please don't remove it. You will regret it. (This is not a threat ;-)  ).  
Having doing trouble shooting in this stack for a number of years I know 
what
I am talking about.

>	     - I partly started separation of dbg_buf and stats_buf,
>	       but code duplication is annoying
>
I don't understand the reason for this. debug_buf() is evidently a 
misnomen,
 since it also is used to format statistics, but the functionality 
remains the same.
What differs in the two cases is only to which memory area they
are formatting, and the purpose of it. Why not simply rename it to 
print_buf(),
string_formatter() or similar and use it the way it is. Code duplication
should be unecessary here.

>	     - Mark is planning to look into this too, so
>	       talk with him first
>
>	3) Cleaning up version 0 message support, i.e. compat_msg.h
>	   and compat_msg.c files:
>             - reasonable small job with very independent part of TIPC
>
>	4) Cleaning up resto of old module handling stuff:
>	     - all code realating to Linux modules should be in
>	       driver.c, but there is still at least some 
>	       MODULES_USE_COUNT lying around
>
>	5) Bottom handler stuff and msg_buf (msg_buf.h and handler.c):
>	     - there is some wierd stuff going there and then I doubt
>	       the queuing stuff is rock solid, but I am very afraid
>	       to touch the code because it can potentially break
>	       TIPC very badly
>
This is one of the few parts of the code I did not touch when moving to 
Linux,
partly because it _is_ vulnerable, and partly because it is, excactly 
that, solid. The
weirdness is of course due to my zeal for performance, which sometimes makes
the code difficult to understand. I think this is worth the price in 
critical parts
of the code.

>
>	6) Getting rid of C++ naming scheme:
>		- tipc_fooBar => tipc_foo_bar
>		- typedef struct FooBar {/*...*/} FooBar;
>		  => typedef struct foo_bar {/*...*/} foo_bar_t;
>
>	7) Replacing long macros (#define foo() with several lines
>	   of code) with static inline's
>	        - plenty of those ...
>
Macros are used in the core because certain compilers (at least one used
within Ericsson)  don't support inlining. I can't see that they hurt, 
except
from an  aestethic viewpoint.
But once again, I know you guys don't care about portability...

>
>	8) Renaming stuff. i.e. the term mapping:
>	     - The map is from top to bottom:
>		  TIPC (Jon's code)	v2.5 TIPC
>		  =================	===========
>		  Network		network
>		  Zone			zone
>		  Subnetwork		cluster
>		  Manager		manager
>		  Processor		worker
>		  Device Processor	slave
>	     - This really is not very important, and is better done
>	       when you are doing modifications anyway to the code
>
Manager, worker, slave ?  :-)
It is funny, but at least the term 'worker'  is not very illustrative 
for what it
represents in the structure. I would still prefer 'node' or 'processor'. 
The idea
that cluster == subnetwork, i.e. potentially different from a zone has 
occurred
to me earlier, and I like it.
It will even solve a potential addressing space problem.

>
>Please note that I am still far from happy with filenames, and will bhe
>changing them, so I would suggest you pick one file, do changes, and
>sync them (= send patch) with me ASAP. My plan is put an update at least
>once a week to http://www.osdl.org/archive/mika/.
>
>Cheers!
>
>--MiKu
>
>
>_______________________________________________
>cgl_discussion mailing list
>cgl_discussion at lists.osdl.org
>http://lists.osdl.org/mailman/listinfo/cgl_discussion
>  
>




More information about the cgl_discussion mailing list