Messages in this thread | | | Date | Sat, 23 Oct 1999 13:24:18 +0100 (GMT) | From | Riley Williams <> | Subject | Re: 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/
| |