lkml.org 
[lkml]   [1999]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: serial.c (half duplex support)
    Hi Ted.

    >> Anyone who really needs this kind of support is probably going
    >> to end up writing their own driver which uses the serial port
    >> hardware directly, like the irport one already does.

    > We have such an interface already; it's the line discpline.

    I have to admit that I'd forgotten about that...

    > Granted it's doesn't have the right hooks for a half-duplex
    > device driver, but it's probably not that hard to put those
    > hooks in.

    I don't have much experience of half duplex protocols outside of the
    amateur radio world, but there are certain hooks that appear to be
    obvious starting points, as follows:

    1. Use of a half duplex protocol implies that the serial port
    has a flag indicating its state, with four valid states, as
    follows:

    a. RECEIVING - This port is currently receiving data, so
    anything to transmit is just queued until
    reception finishes.

    b. RX-TO-TX - This port is in the process of switching
    from reception to transmission of data.
    This would only occur when the receiver
    has been idle for a predefined length of
    time AND the transmit buffer is not empty.

    c. TRANSMITTING - This port is currently transmitting data,
    so is not able to receive anything.

    d. TX-TO-RX - This port is in the process of switching
    from transmission to reception of data.

    2. Half duplex protocols are generally receiver driven, with
    a station wishing to transmit waiting for a clear channel.
    This suggests the first two hooks:

    a. A routine to be called to say "The receiver has not
    received any data for X units of time, and there is
    data waiting in the transmit buffer", with X being
    an attribute of the serial line, similar to those
    that already exist (such as close_delay). This would
    move the line into RX-TO-TX mode.

    b. A routine to be called to say "The transmitter has
    run out of data to transmit" which would move the
    line into TX-TO-RX mode.

    Comments?

    > I'd rather try to expand the line discpline to have the right
    > interfaces for those sorts of protocols, than try to invent a
    > new interface in addition to the line discpline structure; it's
    > a matter of what's the cleanest way of doing things.

    I'd certainly agree here.

    > Also, that way it's much more likely to work with other tty
    > device drivers (although it'll probably require a few changes to
    > each driver to support calling the line discpline when hardware
    > transmit buffer is empty, and so on).

    True...

    Best wishes from Riley.

    PS: The kernel versions page is now back online at the URL below, and
    includes separate sublists both for each kernel series, and for
    each year of development.

    +----------------------------------------------------------------------+
    | There is something frustrating about the quality and speed of Linux |
    | development, ie., the quality is too high and the speed is too high, |
    | in other words, I can implement this XXXX feature, but I bet someone |
    | else has already done so and is just about to release their patch. |
    +----------------------------------------------------------------------+
    * http://www.memalpha.cx/Linux/Kernel/


    -
    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:54    [W:4.216 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site