[openib-general] Re: [PATCH] opensm: remove osm_pkey_mgr.h

Sasha Khapyorsky sashak at voltaire.com
Mon May 22 06:43:47 PDT 2006


On 13:55 Mon 22 May     , Eitan Zahavi wrote:
> Hi Sasha,
> 
> My point is simple:
> 
> OpenSM has a very structured skeleton:
> 1. All mad receivers have two c files and two h files
> 1.1  mad receive controller which deals with dispatcher registration . 
> 1.2 Mad receiver which deals with all the action happening after such a
> mad is received
> 2. All algorithm stages (managers) have a c file and h file
>     An algorithm stage might be lid assignment, routing, partition
> enforcement etc
> 3. All SMDB objects have a c file and h files. 
>     Examples are Nodes, Ports, Multicast registrations etc
> 
> These are the structural code rules for OpenSM. 
> 
> Even if you think it is better to merge functionality and avoid having
> some of these h files and you might even be able to save some lines of
> code by doing that, you break the code structure. If you personally like
> to work with flat code - this is your preference.
> I prefer having clear structure. So if I need to know where is the pkey
> manager object defined? What are its internal state variables? What are
> the algorithms it uses? Etc I can simply open up osm_pkey_mgr.h and find
> this out. 

I would be agree with your last example, but it is not the case - what
you will actually find in osm_pkey_mgr.h is some object with no related
to pkey management fields, but instead with four duplicated from
somewhere pointers (and you will need to dig the whole tree in order to
find from where actually it was copied). Do you call this "clear
structure"?

> If you want to redesign OpenSM structure to be "simpler" or more
> "effective" you can propose doing that. But doing it in the salami way
> is just going to hurt stability and leave us with no structure at all.
> Unless we are willing to re-architect the code in a clean manner and
> spend the years of development and validation for these changes - lets
> keep the code with clear structure.

So your proposition is to wait years in order to remove unused object?

Also note that this cleanup has nothing similar with to re-architect the
code, it does not even touch OpenSM architecture.

Sasha



More information about the general mailing list