On Tue, Oct 23, 2012 at 06:45:51PM +0000, Grant Edwards wrote: > On 2012-10-23, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote: > >> Can it be guaranteed that it's going to be fast enough at high > >> baud-rates to prevent any gap between the first byte and subsequent > >> bytes? > > > > Possibly not for some protocols (or worse yet 'almost always' for > > some protocols). > > > > It's something to look at once the basic bits are in. > > > >> I now work for a company that has manufactured PC serial boards for > >> 25+ years, and we still get regular requests for that feature (and our > >> boards do support it -- though our Linux driver does not). > > > > In which case when we get to addressing this it will be good to make > > sure we cover your needs as well. > > 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. What do you mean "lack of long-term stability"? The userspace tty api hasn't ever changed or broken. Don't focus on in-kernel api, that's always going to change, no matter what interface you choose to use in the kernel. Just get your drivers merged into the tree and you will not have to worry about it. thanks, greg k-h -- 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
