Hello Joerg,
This maybe a little off topic, however the next question came in my mind
while reading this letter...
Has there been a thought on passing ax25 utils and other ham-related topics
into other operating systems.
I know a lot of fellow hams have their hands on good stable machines like
free_bsd, and other unix's, but it seems no one has ever tried to run ax25
on them.... At least not that i'm aware.
I'm don't have the knowledge about all the things which get involded when
compiling kernels etc, but i can imagine all these unix's come a lot
together .?. the biggest problem lies in the drivers for the 'in most cases'
specially developed hardware....
Is it true ax25 is only written for linux, or can these utils be easely be
adapted in other unix's .?.
If for instance i look at the z8530 scc card drivers, i don't see any
documents about other systems.. when looking at other program's written for
linux, most of them have documents with them which say they haven been
(succesfully) tested on other unix's .. (hp,sun,etc..)
I myself have not yet been experimenting with my free_bsd partition and my
ax25, because of the simple reason that i have a lot to learn about the
free_bsd itself.. (i have problems accessing my floppy drive ;( ....), and
building a stable kernel is not one of my priorities..
so i am wondering if you know anything about this subject, and maybe know
about some successes on this subject.
i also would like to know about successes form others who read this....
Regards,
Ron Jochems
PD1ACF
The Netherlands.
-----Original Message-----
From: Joerg Reuter DL1BKE <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thursday, February 24, 2000 11:22 PM
Subject: Re: NEW-AX.25 (was: FLEXNET flamewar)
>> (btw this imposes another question, who will maintain the current
>> implementation - which is stable but requires bugfixing or such
>> things like the current 2.3 network driver api change -
>> during this time? Joerg, Tomi?)
>
>I'm maintaining z8530drv (AKA scc.c), bpqether and keep an eye
>on 6pack.c. I haven't dared to touch mkiss.c because quite frankly
>I don't understand that thing and don't have the time to sort out
>the strangeness.
>
>> On the other hand we have some requirements which are partly
>> orthogonal to the above:
>> * Linux has a rather clear seperation between network driver level
>> and protocol stack. In order to have decent timings we _have_
>> to establish some interaction between the to layers, but we
>> should be careful. While browsing the sources and reading
>> recent discussions I come to the conclusion that there is
>> consense regarding ddi_set/get_rts/cts, ddi_get_dcd but
>> there are arguments against setting the bitrate this
>> way?
>
>IMHO the driver should report the bitrate to AX.25 layer, not the
>other way round. But it really doesn't matter which way. I'm against
>setting special hardware features (such as clock modes or driving LEDs)
>or passing down statistical data through the DDI as it's purpose is to
>connect the MAC with the device driver. Everything else is a user
>space problem.
>
>> And (again as a comment to joerg), of course some of the developers
>> are flexnet-biased. But if people using different environments
>> are testing the new stuff and are giving feedback I can't see why we
>> couldn't combine best of both worlds.
>
>Mainly my concerns are about the adaptive scheme. Implementing that
>scheme in user space gives the user the option whether to use it or
>not. Probably provide some startup script with the tools that starts
>the daemon by default and give those who do not want it / need it
>the freedom to disable it themselves. Keeps the kernel part small
>and maintainable -- and a possible next maintainer from the temptation
>to throw it all out again.
>
>> With regard on getting the
>> whole thing into the kernel, I don't think you can compare this
>> with GGI or ISDN. The ax.25 package is something Linus doesn't care
>> much about and if the main ax25-developers are happy with it,
>> he will be too.
>
>Believe me, he cares about it. It doesn't matter how important a
>package seems to him, he decides on basis of the same criteria. Of
>course, a patch that everybody already uses will go in more easily.
>Don't forget, this is already the second _big_ change to the kernel
>AX.25.
>
>We agreed at least conceptionally on Matthias' version, let's
>stabilize it, find the bugs and get it into the shape that it
>will be accepted by Linus. (That's what he requested, BTW)
>Adding new features, bloat.. um, enhancing the DDI, modifying
>the socket API can come later.
>
>My idea of an agenda:
>
>- let obsolete socket API structures as such and let them issue a
> warning (calling bind(), recv/sendmsg(), etc with struct sockaddr_ax25
> instead of full_sockaddr_ax25 or full_sockaddr_ax25 only holding
> 6 digipeaters). I'll do that ASAP.
>
>- port the patch to 2.3 / 2.4
>- keep it updated and get it into 2.5.1
>
>- implement a DAMA slave and a full duplex mode (the first one involves
> a lot of work, the later one is easy)
>
>- throw out obsolete API structures in 2.5.x
>- implement a device name based socket API additionally to the current
> one.
>
>- implement a user space solution for adaptive parameter schemes
>
>- implement ACLs instead of a direct UID -> callsign mapping
>- implement a simple input filter for incoming frames
> (both maintainable through procfs)
>
>Comments? More ideas? How could the new structures for the API
>look like? Did I forget something?
>
>I agree on the other things you mentioned. ;-)
>
>Thanks for the input,
>
>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)
>
>
