On Wed, Dec 09, 2020 at 02:49:45PM -0800, Mychaela Falconia wrote: > Greg K-H wrote: > > > I think we need more review for the rest of the series. This does > > change the way serial ports work in a non-traditional way (i.e. using > > sysfs instead of terminal settings). > > But the problem is that the current status quo is fundamentally broken > for those hardware devices in which DTR and/or RTS have been repurposed > for something other than modem and flow control. Right now whenever a > "cold" (never previously opened) serial port is opened for the first > time, that open action immediately and unstoppably asserts both DTR > and RTS hardware outputs, without giving userspace any opportunity to > say "no, please don't do it". Yes, this behaviour is codified in a > bunch of standards that ultimately trace back to 1970s Original UNIX, > but just because it is a standard does not make it right - this > Unix/POSIX/Linux "standard" serial port behaviour is a bug, not a > feature. Thanks for the long response, but I think you have to realize that creating a new api for something that has been "how things work" since the 1970's should not be taken lightly. No matter if it was a bug or not, changing user-visable behavior is not a trivial thing. What we come up with here has to stand the test of time of being able to be supported properly for the next 40+ years. thanks, greg k-h
