On 2012-10-23, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:
>> FWIW, in some products we're planning that will require support for
>> various industrial serial protocols, I'm leaning towards abandoning
>> the tty driver approach and writing a stand-alone character device
>> driver. The byte-stream oriented tty/line-discipline layer just
>> doesn't fit well when dealing with frame-oriented industrial protocols
>> that depend on things like 9th bit addressing and detecting
>> sub-millisecond inter-byte timeouts. When I add in the lack of
>> long-term stability in the tty API it seems like it might not be such
>> a bad idea to give up trying to make the tty abstraction fit a use
>> case that's just nothing like a teletype.
>
> Not unreasonable but we do need to cover it to some extent because there
> are a lot of 'multi-use' port types where you need to share the hardware
> or switch modes.
Agreed. Providing support for things like 9 bit mode, inter-byte
timeouts, arbitrary baud rates, half-duplex mode, and user-selectable
electrical interfaces (232/422/485/etc.) in the standard tty API would
be a good thing. Half-duplex mode (sometimes called RS485 mode) and
arbitrary baud rate are great recent additions.
> Although we don't use it that way its not entirely accidental that the
> tty buffer code supports chains of buffers with lengths 8)
Thanks, that's good to know.
--
Grant Edwards grant.b.edwards Yow! I can't decide which
at WRONG TURN to make first!!
gmail.com I wonder if BOB GUCCIONE
has these problems!
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
