Hi there: The following posting appeared on the Linux kernel "netdev" mailing list last week. I thought I would repost it here as a service to anyone who is considering using Linx as a clustered computer communication technology (as an alternative to using TIPC). It would appear that, in the reviewer's opinion at least, a lot of work is required before the Linx code would be ready for integration into the Linux kernel; unless there are people out there willing to make a substantial investment to do this work, it seems unlikely that this will happen in the foreseeable future.
Regards, Al -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Hemminger Sent: Tuesday, August 07, 2007 3:39 PM To: [EMAIL PROTECTED] Subject: Linx After seeing this article on Linx http://www.linuxdevices.com/news/NS8613439087.html I decided to give it a quick code review (long airline flight). Overall, it isn't awful, it just looks like every other piece of code that hasn't been managed for mainline kernel inclusion. Nice way of saying, this turd needs a man year or more of polishing. Gratiutious Code Review of Linx 0. Bugs. A. Device names can change in kernel at anytime, use pointers or ifindex. In fact any name change will crash kernel in BUG_ON in notifier B. Device's changing MTU will crash kernel in BUG_ON C. Calling del_timer_sync under RTNL 1. Coding Style A. Typedef's Don't use typedef's like LINX_SPID, ... B. Non-standard naming conventions I. Don't use uint32_t for kernel use u32 or __u32 II. No MixedCaseNames C. Use std. macros I. BUG_ON vs. LINX_ASSERT, etc D. Code in macro's that should really be inline's (e.g. linx_check_linx_huntname) E. Indentation F. Excessive scope, much of the code could be local to one file G. Too many spelling errors H. OS Abstraction layer is unacceptable I. Use initializers when possible (e.g device_notifier) J. Quit with all the assert's for in_irq() in timer's etc... 2. Bogus wrappers A. Kmalloc B. Spinlocks 3. Unacceptable ABI A. ioctl's for special functions B. Heavy reliance on config parameters in /proc C. Looks dependent on Ethernet address format D. Code for non-standard adaptive coalesce and his code has protocol playing with drivers timers directly. E. Non-assigned number for Ethernet protocol 4. FYI A. No __init or __exit B. Kernel API documentation Only document API calls that matter not every pissant little function. Avoid stating the obvious. Why not use docbook format? C. Locking way to fine grained (lots of small locks) Should use RCU and avoid rwlocks Use existing linux network device API locks (ie dev_base_lock, RTNL) if possible. Those who don't understand TCP/IP are doomed to reimplement it, badly. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
