Greg K-H wrote: > To ignore the public, accepted, standard is to become an operating > system that does not follow the standard, which would not be a good > thing at all. So is FreeBSD 13.x a bad OS then, because it offers an *option* of suppressing this particular standard-mandated behaviour? > Again, that is the standard, why wouldn't you want to do that? To not > do that would be to break interoperability with millions of devices out > there (remember modems?) I don't need to "remember" modems, I use them almost every day in my test lab - but none of my proposed patch versions (nor FreeBSD's recent CNO_RTSDTR feature addition) break interoperability with anything, instead both FreeBSD's solution (for their OS) and my proposed Linux patches merely provide an *option* for more specialized hw devices that require different handling. > > The solution implemented in FreeBSD relies on a feature of that OS > > which does not exist in Linux: initial-state devices. > > Linux dropped those a long time ago for good reasons, let's not revisit > that design decision again please. Dropped? Are you saying that Linux once had them at some point in the past? If so, I was unaware of such history - I thought Linux never had them to begin with, just like Classic UNIX (4.3BSD etc) never had them either. But in any case, was I ever asking for ttyXX.init devices to be added to Linux? No, I was not - instead I was merely pointing out why a naive "straightforward" port of the new CNO_RTSDTR termios flag from FreeBSD to Linux wouldn't work. > From what I recall with the original patch series, Johan is the author > of these, not you. Rebasing and forwarding on is great, but please > never drop original authorship of patches, that's just rude, and in > some cases, ripe for legal worries. In the case of the 3 patches which originate from Johan (1/6, 2/6 and 4/6), I submitted them with the following attribution: From: me [...] Co-developed-by: Johan Signed-off-by: Johan Signed-off-by: me My reading of Documentation/process/submitting-patches.rst told me this was the correct protocol - but if I got it wrong, what is the correct way then? Specifically, what is the correct protocol when (in this chronological order): 1) Developer A prepares a patch, and then drops it, i.e., does not continue fighting to get it mainlined; 2) Developer B picks up A's patch and makes further modifications to it, modifications which A might disagree with. > Can you fix that all up, tone down the "this is all wrong" verbage, and > properly resend the series as a joined patch series (your emails are not > threaded properly at all and our tools can not find them correct, just > use 'git send-email' and that would solve it.) and then after the merge > window, I'll reconsider this series. Please accept my apologies for missing the thread-linking headers - I didn't realize until after I sent the series that they were critical for reviewers. I can resend the series with those thread-linking headers added, and also changing the cover letter comments to be more in line with your worldview - but first I need a clarification on the authorship attribution issue above, as it is one thing which, if wrong indeed, would need to be fixed right away. > Also please document what has changed since Johan's original submission > to now, and why it should now be accepted when it was rejected then. The main change is not in the patch code, but in circumstances: in between then and now, I have discovered that FreeBSD's solution actually works correctly (unlike Johan's superficially-similar-sounding termios flag proposal for Linux) in that it does NOT tell users to "please suffer just once" on the very initial open of a freshly plugged-in USB serial device. Also FreeBSD's release process is slower than Linux', and as a result of this slowness, the feature addition in question only appeared in a release in 2021-04 - some months after my previous attempts here - even though it was committed to FreeBSD HEAD in 2019. This new development in FreeBSD shines a flashlight at Linux being the backward one here, and I was hoping that this new change in circumstances would help create an impetus for making the fix in Linux too. As far as actual code changes between Johan's original patch version and my current modified version, there is just one code change and one significant comment change: Code change: I have renamed the sysfs attribute from nordy to manual_rtsdtr, with a similar name change for the internal flag, which IMO makes it clearer what it is actually happening and why/when this special mode might be needed. Comment change: I removed all references to the termios flag idea (which was Johan's repeatedly-stated longer-term goal and desire), as that one can never work acceptably for the present problem in Linux, or in any OS that lacks initial-state devices. Oh, and there was one place in the code (DTR/RTS assertion in serial_core.c, applying only to "hard" serial ports and not USB) which Johan missed in his patch series, an omission which I only noticed when preparing my current series - hence patch 3/6 is my original work. M~
