This is a revision of my original proposal to take in information
since received, not a duplicate, but I've revised it to state what
appears to be the current requirements:
1. The serial port will provide a flag field to indicate
its state, with the following states being defined:
a. NOT-HERE - This port is not present. This is the
default state for all ports in the kernel
before any probes occur, and is the only
valid state for ports that are not found
to be present.
b. FULL-DUPLEX - This port is currently operating in full
duplex mode. This is the default state
for all ports for which the hardware has
been detected.
c. FULL-TO-RX - This port is in the process of switching
from full duplex mode to half duplex
receiving mode.
d. RECEIVING - This port is currently receiving data in
half duplex mode, so anything to transmit
is just queued until reception finishes.
e. RX-TO-TX - This port is in the process of switching
from reception to transmission of data in
half duplex mode.
This would only occur when the receiver
has been idle for a predefined length of
time AND the transmit buffer is not empty.
f. TRANSMITTING - This port is currently transmitting data
in half duplex mode, so is not able to
receive anything.
g. TX-TO-RX - This port is in the process of switching
from transmission to reception of data in
half duplex mode.
h. RX-TO-FULL - This port is in the process of switching
from half duplex reception to full duplex
mode.
2. The following hooks should be implemented:
a. A routine to be called to say "Time sufficient for X
bytes to be received has passed without reception of
any bytes, and the port is in the RECEIVING mode" (as
defined above). The default is for this routine to be
called only if X (an unsigned quantity) is non-zero.
b. A routine to be called to say "This port is in the
TRANSMITTING mode and has run out of data to send".
c. A routine to be called to switch the transmitter when
any of the transitions (1.c), (1.e), (1.g) or (1.h)
need to occur.
3. The following additional IOCTL's should be implemented:
a. One to specify the value of X as referred to in (2.a)
above.
b. One to specify that the port should switch to state
Y (as defined in (1) above) now.
>From an implementation viewpoint:
2.a could be implemented along the lines of "On receipt of
each byte, set a timeout to expire when the time needed
for X bytes to be received has passed, resetting any
such timeout that is currently in progress for this
port. Should this timeout actually occur, call the
specified routine."
2.b would be implemented fairly easily, and the default
response in the absence of any other would be to cause
transition (1.g) to occur.
2.c would be specific to the individual line disciplines.
Comments?
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/