Hi all, I've got two things to announce: First the good message: I fixed another severe bug in the AX.25 LAPB state machine implementation. I prepared another patch against Alan's Linux-2.2.20pre11 tree. It should also apply against the final 2.2.20. You can download the patch as usual from my homepage: http://www.afthd.tu-darmstadt.de/~dg1kjd/linux-ax25 This package also contains the latest (improved full-duplex handling and rock-stable) PCISCC-4 drivers. Libs, tools and apps package are there as well. The bad message, which some of you already know about, is that I am giving up the AX.25 maintainer job. I never actually intended to perform this job for a longer time but only to replace Mat for a limited period of time, which turned out to be longer than expected and still with no end in sight. ;-) There are two basic reasons for my decision: 1.) Job My life changed quite drastically in the last years. Meanwhile I finished my studies, left University and am now 100% exposed to the real life [TM]. My new job here in Dresden is currently taking up all my work- and spare time (plus a little more ;-)). I don't think there is need to comment any more on this as most of you probably know what I am talking about and the rest will find out soon. :-) 2.) Motivation My motivation to perform the play the maintainance role converged towards zero in the last years. When I took over the job I meant to collect patches from people, evaluate feedback and produce a working Linux AX.25 implementation whose kernel module was to be integrated into Linus' development tree in the near future. The current situation is that I received litte-to-no feedback, an integral amount of maybe seven or eight patches from two or three different people and my basic task is to figure out which brain-dead symptom-fixes that somebody sneaked past Linus broke my patch when preparing the latest release (which costs me a couple of hours to do right each, including updating the web site). Still, there are still lots of issues to fix and things to implement, but instead of pulling on one lope people prefer to point newcomers and people willing to test and write documentation at the old, messed-up-beyond-repair stuff in the mainstream kernel, at the same time preaching on exhibitions how great the Linux amateur radio support in-kernel is. Ironically this situation pretty much constitutes what I predicted and warned about at the last PR conventions concerning the whole PR society: Coordination- and conceptless playing around without a clear strategy to bring PR back to life. Anyway, I feel it would the wrong approach to simply forget the rest of you and disappear from kernel development without a comment. Therefore I am providing my TODO-list that a future maintainer could pick up and work his way through in order fix the remaining issues (which, admittedly, are quite a few): TODO list for kernel-AX.25: --------------------------- - Timer routines The timer subroutines are mostly remaining parts from the old (Jonathan) kernel-AX.25 with all the "fixes" people contributed at that time. This stuff is seriously in need of a complete rewrite. The implementations can be found in ax25_subr.c, ax25_subr.h, ax25_lapb.c and ax25_timer.c . I tried some modifications some time ago but had to revert it under protest because it did not work too well. Part of that was a unification on a common time unit across the /proc/sys/net/ax25/*/* parameters. I would recommend using milliseconds. The current state is that the routines more or less work as people are willing to tweak the parameters a bit. A final implementation should be largely auto-adapting. One more thing: Removing the internal timer management (per-interface timer which "distributes" the timer events to the respective VCs is probably overkill. Quite a few lines could be saved by allocating timers on a per-circuit base. Of course the per-interface scheduler should keep its own timer. - /proc/sys/net/ax25/*/media_* - Interface The media parameter interface as currently implemented was only a first shot. It should be implemented with a (string,value)-tuple interface between ax25 and driver modules. The functions for parsing the strings could be provided as an inline function in the ax25dev header file and should be fairly trivial to implement. This, by the way, is something where Linux definitely leaks behind even Windows. A general, generic means of setting/querying device and protocol parameters should be provided by the operating system or network subsystem core so that for example a SNMP agent automatically supports new parameters without extending and recompiling it. - Lib/tools/apps Rewrite The user space tools should be completely rewritten and at the same time adapted to the new proc.* files. Moreover the complicated configuration file/directory structure (especially the messed-up ax25ports file and the two-faced interface names) should be eliminated. - Autorouter (ex ax25rtd) reconceptioning and rewrite A new strategy on how to perform the automatic ax25 route, arp table and IP routing table update should be agreed upon. The current strategy (which we inherited) was to process all incoming packets in user space and then update the tables using the standard APIs and saving/reloading to/from file upon daemon exit/startup. This is a nice quickhack, but no solution, especially when dealing with highspeed links. Keeping large, difficult to handle routing trees in kernel memory is also not a very elegant solution. Our previous idea was to handle routing database management including table maintenance completely in user space and have the AX.25 core "ask" the user space daemon for a route as soon as it needs one using the RTNETLINK mechanism. I am not so sure about it any more. In fact I would prefer doing everything in user space, but more about this later on. - SOCK_DGRAM SOCK_DGRAM class needs to be implemented in order to support applications that are based upon exchange of UI frames. - Add DISC state to LAPB state machine A new state needs to be added to the state machine to handle locally initiated disconnect properly. - Documentation It goes without saying that all documentation is seriously out of date and needs a complete update, dropping most of the old content. I stopped counting the number of emails I got regarding the configuration of the IP coupler and VJ compression engine. A new HOWTO and FAQ would be a nice start. - Update to 2.4.x Joerg Reuter, DL1BKE <jreuter@suse.de> already did a port to 2.4 . His patch could be found on ftp://ftp.ccac.rwth-aachen.de/.../people/jr/... somewhere and last time I checked it was against 2.4.3 . It implements some of the netdev interface, bh handling and locking changes that were introduced during 2.3 . Theoretically the complete stack should be completely race condition free like my 2.2 tree but also under SMP conditions by introduction of fine-grained locking. Unfortunately I think Joerg did not keep up with my latest changes and bugfixes (starting from the 2.2.17 versions or something) so these need to be integrated. Otherwise the package should make a pretty nice starting point. - DAMA master In order to really meet node requirements the DAMA master as outlined in the ax25_ddi scheduler function should be implemented. This sounds more complicated than it is because the clean concept of the scheduler actually makes it pretty easy. Alternatively here is a concept of how I would approach the implementation of a AX.25 system under Linux when considered from scratch. During the last Darmstadt conventions we pretty much came to the conclusion that AX.25 in kernel, especially with the advanced functions such as hop-2-hop digipeating and flexnet routing isn't a very good idea at all. The reasons that were generally quoted in favor of it were: (1) Low latency: Kernel functions can react to external events such as change of channel state in a very quick and pretty much deterministic manner. (2) Socket interface: The protocol implementation can interface to user mode applications using the standard BSD compatible socket interface. IP frames can be forwarded using the standard core network mechanism. These days (1) is not a problem for user space applications any more. Like other modern operating systems Linux contains several realtime schedulers (which, especially in combination with the full-preemption patches) pretty much guarantee similar latencies for user space applications. On the other hand (2) could be emulated using a kernel mode stub communicating with a user space protocol implementation using RTNETLINK. So I would propose constructing a user-mode network stack that would interface with non-standard (serial device) drivers (like PCISCC, SCC, baycom_ser, ...) using standard char devices. The char devices should support read() and write() primitives to perform data transmission and reception as well as several blocking and non-blocking ioctl()s to convey channel states and parameters. Serial-based drivers (6pack, KISS (sigh)) could be implemented directly. BSD socket compatibility could be re-introduced with the kernel-stub- and-RTNETLINK-approach outlined above. This is by the way the same concept that PC/FlexNet32 on Windows NT uses, where it seems to work pretty well. It would even invite the porting of FlexNet to Linux. The only problem is that due to a.) is Micro-Kernelishness and b.) susceptibility of propertary software linkage it would probably be very difficult to sneak past Linus. But hey, you cannot satisfy everyone. ;-) I know at least of one already existing AX.25 protocol stack besides Flexnet that could be plugged easily into such an environment and is even cleaner and more performant than my/Mat's implementation.\\ Anyway, I hope the time I took to write this was not completely wasted and people take the time to address the deficiencies and ideas pointed out. Hoping to see some of you at the next PR convention / ham exhibitions, -- Jens P.S.: I will unsubscribe from linux-hams right now, so if you got questions/comments feel free to CC: or mail me at my AFTHD address. - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
