[speedtouch] Re: Getting close Was Not your normal Speedtouch Woes!

2003-11-18 Thread KnuX
I know that my comment is not in the subject, but... How can we use the kernel driver ? (compiled as a speedtch.o module ?) ;) KnuX - Original Message - From: "Duncan Sands" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Edouard Gomez" <[EMAIL PROTECTED]> Sent: Monday, November 17, 2003

[speedtouch] Re: [CVS commits] Various small things

2003-11-18 Thread Leonard den Ottolander
Hello Edouard, > I guess the sourceforge anonymous cvs is still in a pity state and > lagging way behind the developer cvs access. > > This patch was already applied with the changes I listed. It was not a > patch modification request but a report. Let's blame sourceforge that > made

[speedtouch] Re: [CVS commits] Various small things

2003-11-18 Thread Leonard den Ottolander
Hi, (One man thread :) > Correction. unused_cells is initialised to lbuf at the first loop, and the > value of unused_cells is changed to atm_pointer by the call to > aal5_frame_from_atm_cells. This is probably a way to walk through lbuf. Ie > the use of unused_cells instead of lbuf makes sens

[speedtouch] Re: [CVS commits] Various small things

2003-11-18 Thread Edouard Gomez
Leonard den Ottolander ([EMAIL PROTECTED]) wrote: > The two checks whether pti == 1 can be merged. Dropping the "idiotic > frame length" check, using the constants from atm.h, renaming n1 to > nb_cells, moving the declaration of nb_cells inside the if (pti == 1) > and simplifiying the payload

[speedtouch] Re: [CVS commits] Various small things

2003-11-18 Thread Leonard den Ottolander
Hi, I wrote: > > The lbuf usage is still needed, it's the reading buffer. unused_cell is > > just a pointer that keeps tracks of pppoa3 progress into the read buffer > > if there are still ATM cells left in. > > Then that should be changed back. The current patch doesn't seem to use > lbuf a