Tim Woodall ([EMAIL PROTECTED]) wrote: > +#define BRIDGING1483_HEADER 12
Don't try my previous patch it is really bad, per example BRIDGING1483_HEADER is only 10 bytes long but i've confused by the original patch that was just a quick hack to make the patch as small as possible. And to avoid to have a couple more pointers to the receiving buffers, the author kept the leading hdlc bytes that he overwrites with 0xaa 0xaa, but of course these 2 bytes were not part of RFC 1483. > I can imagine a change later > > /* Use double buffer so we can process one packet on one cpu while receiving > another with the other cpu */ > > unsigned char read_buffer[BUFFER_SIZE * 2]; why ? if the process is scheduled then its pages are swaped in (if not already in active pages) by the VM subsystem. And as most of the time aal5 frames built by the driver are 1 or 2 atm cells long(2*53 bytes), this represent only 2 pages (2*4kb on typical x86 or ppc archs)(one page for the receiving buffer and one for the sending buffer). I don't see the real benefit of having a unique buffer, as we will have the same 2 pages (@ &buffer[0] and @ &buffer[BUFFER_SIZE]) that will be swaped in by the VM. Could you explain your point of view a bit more ? > - n = ppp_read(STDIN_FILENO, ppp_read_buf, BUFFER_SIZE); > + n = read_source(fdin, source_buf, AAL5_MAX_SIZE); > > It isn't immediately obvious that AAL5_MAX_SIZE <= BUFFER_SIZE > > At the very least there should be a > #if AAL5_MAX_SIZE > BUFFER_SIZE > #error "AAL5_MAX_SIZE must not be bigger than BUFFER_SIZE" > #endif > True... but who is really hacking this code source ;-) > There is a similar thing in read_from_usb_thread but its more obviously > correct (53*64)<=(BUFFER_SIZE) :-) True again. > Finally, can you apply (or comment upon) this patch which is required to > fix a number of potential SIGSEGV problems that could affect anybody > (although, to the best of my knowledge only one person has experienced > one). In particular, if the last cell of a frame is a management cell then > you will get a core dump currently. Sure, it does not hurt so it's accepted. -- Edouard Gomez Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:speedtouch-request@;ml.free.fr?subject=unsubscribe
