> (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)
PGP signature
