lkml.org 
[lkml]   [1998]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Writing driver for sync serial board
    Date
    From
    Krzysztof Halasa wrote:
    : Jan Kasprzak <kas@informatics.muni.cz> 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
    layers:

    - 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.

    -Yenya

    --
    \ Jan "Yenya" Kasprzak <kas at fi.muni.cz> http://www.fi.muni.cz/~kas/
    \\ PGP: finger kas at aisa.fi.muni.cz 0D99A7FB206605D7 8B35FCDE05B18A5E //
    \\\ Czech Linux Homepage: http://www.linux.cz/ ///
    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 majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/faq.html

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