[lkml]   [1998]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Writing driver for sync serial board
    Krzysztof Halasa wrote:
    : Jan Kasprzak <> writes:
    : [about a driver for (a)sync serial board]
    : > The main question is how to structure the driver to allow these
    : > modes. Should I register_netdev() three interfaces (rawip, sppp and hdlc)
    : > for each channel I have, or should I have one net interface per channel
    : > and switch modes on the fly (maybe via an ioctl() on the corresponding
    : > character device).
    : I've been hacking Riscom N2 drivers for some time, and I think it is best
    : to have three interfaces per port, and while one is open - block the rest.
    : That way you don't need to use any additional software - just ifconfig
    : is enough.

    I think I will abandon the raw-IP interface and use the way Alan
    Cox used in its driver - what he has is in fact a support routines
    for both sync PPP and Cisco HDLC including a SLARP keepalive support.
    I just need (someone) to port the syncppp.c to the latest 2.1 kernel,
    as this is the version I use for my development.

    : I believe the hardware driver has to:
    : - open/init the board
    : - close the board
    : - open a port (speed, options like clock source, etc)
    : - close a port
    : - send a frame (for example, a HDLC frame - queue it)
    : - receive a frame (from internal queue)
    : - get statistics?

    This design will not allow the driver to work as a character device.
    I have currently the following interface between the HW layer and the upper

    - probe for the board[s], register_netdev() for each channel and
    register_chrdev() for the driver.
    - close the driver (cleanup_module()).
    - queue the frame to the channel.

    and three call-back routines which the upper layer can set for each channel:

    - char *frame_received(int size) -- the hw layer calls this from the
    interrupt routine. The upper layer should return a pre-allocated buffer
    of a given size, the hw starts transfer to it. The upper layer can
    return NULL telling the HW to reject/drop the frame.
    - rx_done() - the frame has been received.
    - tx_done() - the queued transmit has been finished (the upper layer can
    for example set dev->tbusy to 0 or wake_up() the queue of writers
    in chardev mode etc).

    So configuring the channel of the sync serial board means only
    to allocate a private structure for chardev, HDLC or PPP mode and sets
    three pointers to the callback routines.

    : There should be some serial core, and the hardware driver should register
    : itself with it, like in case of sound drivers.

    I am not sure how general this interface will need to be. There may be
    some super-smart boards which could do a SLARP keepalive themselves,
    or some dumb ones which even cannot do the start/end of frame marks.

    : I've been thinking of (re)writing SDL driver that way, but got no time yet.

    I think currently the best interface is the one Alan have in its
    hostess_sv11 driver, so we should probably modify the other drivers to use it.
    The only one thing I don't like on his interface is, that the driver
    registers its own "hdlcX" netdev. I think there should be some
    struct sppp_operations and the sppp/hdlc layer should register its own
    interfaces. It looks very dirty to me when the hostess_sv11.c registers
    the "hdlcX" interface (and even needs to try to get_dev("hdlcX") until
    it founds the first unused "hdlcX" device :-| ). It should be
    the similar way as the ethernet uses - ethernet low-level drivers
    does not look for their own first free "ethX" name.


    \ Jan "Yenya" Kasprzak <kas at>
    \\ PGP: finger kas at 0D99A7FB206605D7 8B35FCDE05B18A5E //
    \\\ Czech Linux Homepage: ///
    If there are race conditions in programs fix them. The "my programs suck fix
    something else" mentality leads you to things like Java. -- Alan Cox

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

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