> 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. Although we don't use it that way its not entirely accidental that the tty buffer code supports chains of buffers with lengths 8) Alan -- 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
