[lkml]   [1997]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.0.30 serial.c, ppp.c and pppd-2.2 questions

    I just finished taking a quick look at Rob's patches, and besides some
    design problems I have with it (if you specify an FIFO size which isn't
    supported by your UART, it silently turns the FIFO completely *OFF*,
    which may be a bit surprising to the user), there's one big problem with
    the patch.

    It currently works by scheduling a post-flush tqueue handler which
    enables RTS and RDI if they had previously been disabled. This is a
    problem, because the line discpline may have cleared RTS because its
    upper level buffering had filled. So simply always enabling RTS after
    the line discpline flush is a bad thing, and may result in significant
    numbers if the line discpline needed to exert flow control for some
    reason. This isn't an issue with PPP (which is probably why Rob didn't
    think of it), but it is an issue with the N_TTY line discpline.

    So I wouldn't apply this patch at all if you use any non-PPP
    applications on your serial lines (i.e., dialup login, UUCP, etc.)

    By the way, given that the PPP is already wasting CPU time to check the
    flags field (which is unnecessary, given that it's calculating a
    checksum anyway, and you optimize for the common case, which is a
    non-corrupted packet), you might as well have it check to see if there
    are FIFO overruns and have it print a warning diagnostic. This way
    you'll be able to distinguish between FIFO overruns caused by interrupt
    latency, and flip buffer overruns.

    - Ted

     \ /
      Last update: 2005-03-22 13:39    [W:0.019 / U:15.320 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site