Hi Jan et al
> To be more exact. We definitely *should* add downcall from hdlc to its
> drivers to immediately start TX.
> BUT that requires quite good knowledge of respective drivers and their
> function. Maybe their authors could add it.
> Again this relies only to HDLC.
I agree with you on at that point.
> > > Second problem is what should driver do when it receives new data
> > > while sending txtail. Since new ax25 is designed that driver just sends
> > > what it gets from higher level it seems obvious it should send new data
> > > and restart txtail. But shouldn't there be some flag so that does not
> > > happen ?
> >
> > If its sending txtail then the transmission is complete - thats it. The new
> > data has to wait!! At least thats what I think is relevant. Consider higher
> > speed interfaces using this code and full duplex implementations as well before
> > changing too much.
>
> Problem is:
> Driver is sending txtail but higher level decides to TX some more data.
> There is no flag preventing that. It is unlikely to happen but it's
> possible. This is all-drivers problem (not just hdlc).
I had the same trouble when coding the PCISCC driver. I decided to abort the
txtail flag sequence and start data transmission skipping the txdelay section.
I think this is the easiest and best solution.
> > Have you by any chance done anything about the fact that the MTU is hard coded
> > in hdlcdrv and hence full of potential lost packets for all the drivers that
> > use it? See my ideas from 20th January in the "Can't get packet length over 338
> > bytes when using SCC card." thread
>
> I'll look at that ..
Of cause MTU should be adjustable, without doubt. What bothers me more is what
to
do about MRU. With DMA controlled devices this is really an issue because you
have
to allocate receive buffers "in advance". I think what most drivers do is
assume
MTU = MRU ?
-- Jens
