Re: [Tipc-discussion] New file release tipc-1.3.10

[Jon M. <jon...@er...>]

Ok, I think we should do the following:

- Remove the 2.4/2.6 directory, and put everything back in one
directory.
   I talked to some people from MontaVista a few days ago, and it seems
like 
   the 2.4 support is not that important for them, so we can skip that
altogether.
- Remove all "placeholder"  code, like the whole contents of proc.c, and
the 
   inter-cluster configuration code in cfg.c. This code  can be
re-introduced once 
   it is redesigned and functional. We get rid of almost all the #ifdefs
this way. 
  The MODULE flag can also easily be removed, as Mark pointed out. If
there is
   more we should consider each case.
- We go systematically through the code and replace (where possible) the
linear 
   linked lists with the Linux supported ditto. 
   The exceptions are places in the core where we  have queues (there
are two such, 
   I think) of  sk_buffs. To retain a minimum  level of OS portability
for the core 
   code I still insist that sk_buffs should only be accessed via
macros/inlines, inclusive 
   any next/prev pointers.
- Re-run Lindent on everything. 

Anything more ?

I will delay the announcment at LKML until this is done. (-Anything to
avoid being 
welcomed by flames from the community ;-) )

Can I hope to get any help with this ?

Regards /Jon
   

Mark Haverkamp wrote:


On Thu, 2004-04-29 at 08:15, Jon Maloy wrote:

  

Do you suggest that we delay the LKML-announcement until we have done

these changes ? To replace all the linked lists is intrusive, and it

may 

take weeks re-stabilize the code. Otherwise, see my comments below.



Regards /jon

    



Steve Hemminger said to send to   lin...@vg...
<mailto:lin...@vg...>  also.



  


[...]





  

Also, I think that in the long run, that the 2.4/2.6 ifdef code will

      

I see there is one I forgot to remove in driver.c, otherwise I think

this is already

done.

    



I talked with a couple people here about the 2.4/2.6 code directories. 

They said that code submitted for review should be for 2.6 only and not

have it set up for both versions of the kernel.