> > How about providing the data needed for the calculation through the
> > netlink device and let a user space daemon do the calculation? Set
> > reasonable default values so that everything still works w/o the
> > daemon running. In my opinion it's worth the extra work. We'll
> > need a way to disable the adaptive mode anyway as it isn't apropriate
> > for every case.
This is the way to go I think. The interface to adjust the channel
access parameters by a user space deamon can be the same as the one
for manual intervention. In fact we need 3 /proc entries: One
for turning off kernel-internal computation, one for adjusting ppersistence,
one for slottime. The latter ones could also be used to read back the
current values in auto-mode.
> > > - retransmission of I+ instead of sending RR+ only for packets shorter
> > > than 40B. Maybe we could increase this value, but not blindly resend
> > > 255B packets.
The ratio of the ration of [the difference between 256B and 40B] and overhead
intervals, such as txdelay and txdelay gets smaller as bitrate increases.
With higher speed you may really want to send an I(P) independend of the
size of payload => /proc entry.
> I'm more concerned about other users on the channel .. but this thing
> needs to be experimented with ..
>
> > > - ax25_check_iframes_acked restarts (t1/t3) timer at any case
> > > we should restart timers when we get new packet ..
> >
> > This is a frame collector issue, right? Please think it over _very_
> > carefully if your patch is correct, I have the feeling that the
> > current behaviour is correct.
>
> We have received new packet, if there is nothing unacked we should restart
> T3 since we know our partner is there. If there is something to be acked
> we should restart T1 since there may be some packet after it with correct
> number.
> And that has nothing to do with frame collector.
You are right, one of the timers T1 and T3 have to run in any case to avoid
deadlock conditions. Even with DAMA you have to run T3, but you may decide
to disconnect the VC as soon as T3 runs out.
T1 needs to be restarted with every received in-sequence I frame.
> > > - when we send DISC+ and get UA or DM socket is now closed immediately,
> > > there is no need to keep it (I consider that a bug)
> Weird things happen without that. Disconnected socket is kept until T3
> expires which is _very_ annoying especially while testing anything
> (combined with strange link-reset which happens when you try to connect
> again. I think closing immediately is the right behaviour.)
We had more than one discussion about this behaviour with Mat and Gunter.
Both are of the opinion that this is not the right way to solve the problem.
As far as I�m concerned, I think it is - at least temporarily - OK. I
will add this to the patch since a lot of people send me bug reports about
it.
> I've got some thoughs about whole AX25 should be done in userspace .. but
> now we would throw away almost everything what has been done ..
> Userspace AX25 would have many advantages .. portability not being
> smallest of them.
I have no problem with throwing away something if this is the RightThing [TM]
to do. But here I�m not quiet sure about this. There three main problems with
this, being of cause
1.) socket interface
2.) synchronous driver interface
3.) realtime scheduling
Drivers need to stay in kernel mode anyway (I don�t think implementing a DMA-
controlled driver in user space is a lot of fun) so that makes 2.) the biggest
problem.
Do you have a working concept or some ideas how to solve these?
-- Jens
