>>>> 1. The serial port will provide a flag field to indicate
>>>> its state, with the following states being defined:
>>> Most of this state (RX-TO-TX, RECEIVING, FULL-RX, etc.) should
>>> be implemented in the line discpline, since it's highly specific
>>> to the half-duplex transmission discpline.
>> However, the state as designed is basically generic to ANY half
>> duplex line discipline and, as a result, would be best
>> implemented as a core module for half duplex disciplines, with
>> the individual disciplines hooking into it.
> That's fine, as long as all of this gunk isn't in each
> individual low-level tty driver.
As I see it, the ONLY part of all this that belongs in the individual
tty driver is this part:
1. When the driver is called to probe for the relevant hardware,
it finds the state flag set to NOT-HERE.
2. If the driver finds the relevant hardware present, it sets
the state flag to FULL-DUPLEX.
...and possibly also this part...
3. When the driver gets called to do anything later, it checks
the state flag, and if it finds it set to NOT-HERE, it just
returns an error based on that fact. If it finds it set to
any other value, it ignores the specific value and just gets
on with its job.
...although that would probably be better placed higher up. Basically,
the line disciplines will need to be able to rely on the fact that the
state flag saying NOT-HERE guarantees that the hardware is not present
and the ONLY place where that decision can be made is when the code to
determine whether the hardware is present is actually run.
> The phrase "the serial port will provide" is what set me off -
> this is something that's specific to the line discpline state
> management, not the serial driver.
Ah...can I apologise for that, but I was wording it as seen from a
user level application. Seen from that viewpoint, the serial hardware,
the line discipline, and everything in between, all comprise a single
unit that normally gets referred to as "the serial port".
> I think we're in violent agreement; it was just the wording that
> made me worried.
Nodz - and LOL at your phraseology...
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/