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