> Could someone please enlighten me what dev-hams is?
A semi-closed mailing list for discussions about details of the
Kernel AX.25 development discussions. The archives are open to
read for everyone, though.
> As far as I�m concerned, I think that
> in the current stage of packet radio developent on linux we should not
> bother with binary compatibility between with applications.
I strongly disagree here, especially as the number of people who use
it is quite high by now. Even small changes have caused a lot of
discussion and problems in the past.
> AX.25 with linux kernel has not yet reached even alpha software quality
> level -
Jens, this is an insult to everyone who has commited enormous time
to develop, test and stabilize it. The code sure has some problems,
the reason is that it has to run under many extremely different
conditions and that it partly predates the current Linux network
implementation. But it is quite stable and reliable. Compared to
industrial *production* code I've seen, it is an astoundingly clean
implementation.
Please stop this "it's all crap, we should build it all anew"
attitude. It is not helping anyone.
> Joe user, aka people who are not able to recompile a package by cd�ing
> into its directory and typing "make clean && make && make install" are
> IMHO not suited for helping in the development process.
There is more to it -- My packet radio machine is a glibc-2.0 system
without development tools. My work station is a glibc-2.1 system. To
compile a new LinKT version (for example) would mean that I'd practically
have to re-install my packet radio computer. Which happily runs 2.3.42
_and_ an old version of LinKT right now.
The next problem is that we have the AX.25 API in the glibc headers.
Jens, please read the threads about ISDN development in the linux-kernel
mailing list archives and why Linus refuses to merge large parts of it
into the kernel tree.
And again, I do not see a _single_ reason to break binary compatibility
for applications apart from ax25spyd & Co.
> > Programs use full_sockaddr_ax25 but sockaddr_ax25 is part of it. You mean
> > removing it as a separate struct?
We currently have the digipeater-less sockaddr_ax25 interface to
bind(), connect(), sendmsg() and recvmsg(). I don't think it works
anymore -- automagical bind() neither. This should be marked depreciated
and go away real soon. We can merge sockaddr_ax25 and full_sockaddr_ax25
and preserve binary compatibility.
> Thats exacty what I mean. The API (including but not limited to the socket
> interface) is far from being complete.
Details?
> Instead of caring about every possible
> combination of application and sub-revision API we should sit together and
> redesign that stuff once for all.
First we should list:
- which features does not work at all?
- which features should be phased out?
- which features are missing?
- what else do we want?
- how can we implement this without breaking applications?
- how can we implement it without inventing [too many] new API elements?
Joerg Reuter http://poboxes.com/jreuter/
And I make my way to where the warm scent of soil fills the evening air.
Everything is waiting quietly out there.... (Anne Clark)
PGP signature
