lkml.org 
[lkml]   [1999]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Synchronous board drivers
    Paul Fulghum <paulkf@austin.rr.com> wrote:

    > So, in a possible implementation, channel capabilities that support PPP
    > negotiated
    > options (such as AFCF compression) are queried by the ppp layer from the
    > channel
    > via ioctl, and the results of the LCP negotiation for supported
    > options are specified by the ppp layer back to the channel by ioctl.

    No, I would see these things as being queried, negotiated and
    specified by pppd, not the kernel ppp layer. Pppd would talk directly
    to the channel via ioctls on a file descriptor which has the char
    device for the channel open (not a fd which has /dev/ppp open).

    > There is still room for a layer that implements something like LAPB
    > with the channel interface on top and the sync interface below. For

    Couldn't this be in a library called by the sync board driver?

    > simple
    > unnumbered information frames on synchronous HDLC, a generic sync driver
    > could implement the extra ioctls call for PPP capabilities reporting and
    > option
    > specification to avoid mid layer overhead.

    The channel code (e.g. the sync board driver) is at least going to
    have to have an ioctl that tells it to connect itself to ppp unit n.
    When it gets that, it will call register_ppp_channel() (e.g.) and then
    it will call ppp_channel_input() with skbuffs containing received
    frames, and its ppp transmit routine will get called back with skbuffs
    containing frames to transmit. There should also be an ioctl to tell
    the channel to disconnect itself (i.e. call unregister_ppp_channel).

    I would see those two ioctls as being the minimum. The channel code
    could also support ioctls to tell pppd that it can/can't do ACFC and
    to let pppd enable/disable ACFC, etc. For some sorts of channels
    there will need to be more PPP logic, e.g. for doing async escaping,
    FCS calculation, etc. In other words, not all of the PPP logic is in
    the PPP layer.

    >
    > Just my 2 cents. Whatever is decided, I'm perfectly happy to write to
    > the new interface.
    >
    > --
    > Paul Fulghum
    > paulkf@austin.rr.com
    >

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

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