From:	 Jens David <dg1kjd@afthd.tu-darmstadt.de>
To:	 linux-hams@vger.kernel.org
Subject: [Announce] New AX.25 release and signoff from maintenance
Date:	 Mon, 12 Nov 2001 00:42:43 -0500
Cc:	 linux-net@vger.kernel.org, a.kurpiers@nt.tu-darmstadt.de,
	 dl4zx@afthd.tu-darmstadt.de, matze@stud.fbi.fh-darmstadt.de,
	 rob@pe1chl.ampr.org

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.
-
To unsubscribe from this list: 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