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

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

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

Mark Haverkamp wrote:


On Tue, 2004-04-27 at 16:58, Jon Maloy wrote:

  

Hi all,

I just uploaded a new file release to SourceForge.

I have corrected several bug related to message bundling and

link changeover, plus a very serious lock bug that sometimes

caused my processors to hang when they lost contact with each

other.

I also corrected a bug in the name/network subscription code,

so you will now receive an event for all overlapping, already

existing publications, not only the first one found ;-).

Some left-out symbols were finally exported as they should.

    



[ ... ]



  

Also, I plan to announce TIPC at the LKML by the end of this week. We
must

admit that the code is still in beta status, but as I understand it this


should

be no problem.

    



There are still a few things that I think will have to be addressed from

a style/structure point of view before requesting that tipc be

considered for inclusion in the main kernel tree.



Some files still have non-standard indentation (name_table.c for

instance).  There is a shell script in the kernel tree called Lindent

that runs indent to format source files.

I ran Lindent over all the code a couple of months ago, but some code
has been
added since then. This should be an easy task.






The style documents that I have seen say to use the list_head macros

everywhere and not use other methods of linked lists.

I  generally use linear linked lists, with a zero "prev" pointer for the
first element and a zero "next" pointer for the last, while the the
macros
support only circular lists, as far as I have seen. I have accepted that
we
may use this list support, but have been reluctant to change it in
already
working code, because of the hazard such a redesign involves. In some
cases, like the link's send queue, I think this is impractical and will
cost
performance. 
Let's put this on our TODO list, but fuurther stabilization must have
first 
priority now.






There shouldn't be ifdefs in .c code

The ones that are there now are for excluding code that should be
configurable
from the Kconfig file. Is there any other way ?






You may have seen documents like these already, but I found a few

style/how-to documents on the web for linux kernel/driver code that may

be helpful:



http://graphics.cs.ucdavis.edu/~brettw/insight/linuxcodingstyle.html
<http://graphics.cs.ucdavis.edu/~brettw/insight/linuxcodingstyle.html> 

http://www.linuxjournal.com/article.php?sid=5780
<http://www.linuxjournal.com/article.php?sid=5780> 

http://www.linuxdevices.com/articles/AT5340618290.html
<http://www.linuxdevices.com/articles/AT5340618290.html> 

http://people.redhat.com/arjanv/olspaper.pdf
<http://people.redhat.com/arjanv/olspaper.pdf> 



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.




have to be removed and the macro wrappers for things like

kmalloc(k_malloc) will have to be removed.



When you send an announcement, You should also send to

ne...@os... <mailto:ne...@os...>  where linux network code
is discussed.