On Friday 08 July 2022 18:09:07 Andy Shevchenko wrote: > On Fri, Jul 8, 2022 at 5:54 PM Pali Rohár <pali@xxxxxxxxxx> wrote: > > On Friday 08 July 2022 17:42:03 Andy Shevchenko wrote: > > > On Fri, Jul 8, 2022 at 4:20 PM Pali Rohár <pali@xxxxxxxxxx> wrote: > > > > On Friday 08 July 2022 15:51:01 Greg Kroah-Hartman wrote: > > > > > On Fri, Jul 08, 2022 at 03:26:21PM +0200, Pali Rohár wrote: > > > > > > On Friday 08 July 2022 15:07:43 Greg Kroah-Hartman wrote: > > > > > > > On Thu, Jul 07, 2022 at 10:48:40AM +0200, Pali Rohár wrote: > > > > > > > > On Friday 22 April 2022 16:28:06 Greg Kroah-Hartman wrote: > > > > > > ... > > > > > > > > > > I'm not saying remove them, I'm saying let us not add any more > > > > > > > dependancies on them in order to keep new applications from ever wanting > > > > > > > to use them. > > > > > > > > > > > > Last time you wrote to remove them. Now saying not to remove them. So I > > > > > > do not understand you now. > > > > > > There was a _new_ addition of the ugly SPD_CUST, that's what I believe > > > Greg opposes to. And I support that. > > > > Which addition? I do not understand you. There was not any new driver > > with introduction of SPD support. > > You stated that SPD_CUST is broken in some drivers, so you are trying > to fix a broken ugly hack. Why? Instead of making it rot and be > removed eventually, you pump life into frankenstein. Firstly I got rejection of my other patches because they does not handle SDP_CUST correctly. So I decided to look at those issues and fix it via helper function which can be easily reused in all drivers. So helper function wrap all "ugly" hacks. Then I got reaction that SDP should be removed. Then I got another reaction that that "I'm not saying to remove them" and another another reaction why to be removed eventually. So how should I interpret this? I'm feeling that you are just trying to annoy people with this "do this", "do opposite", "do again it", "do again opposite"... > > > > > I'm sorry, I am totally lost. > > > > > > > > So look what you have wrote? Who is lost here is me. > > > > > > > > > How about starting over and resubmitting > > > > > the changes you want and we can go from there. > > > > > > > > What to resubmit? I do not understand you. In case you lost emails or > > > > accidentally removed them, you can look at them in archive, not? I hope > > > > that you do not want me to copy+paste all existing patches with all your > > > > quotes on them which you wrote into new emails. > > > > > > That change that adds the new user of SPD_CUST? > > > > What you are talking about? Which user? > > This I missed, I was thinking that you are talking about a new user, > now I read briefly and it seems that it's about an existing user. > Anyway, that change I suppose. > > > > In any case the best summary about BOTHER I ever read is this [1] (and > > > an initial steps in picocom [2]). > > > > Is not that example in manpage enough? > > Dunno. > Can you point it out to me? I can't find it quickly. Argh... Have you read emails to which you wrote reply? So copy+paste relevant part from my previous email just for you: "New version of tcsetattr and ioctl_tty manpages would have documented how to use BOTHER (it is currently in the manpages git)." Plus in past I also pointed to the extended version of that example from manpage which is currently in my repo on github: https://github.com/pali/linux-baudrate.git > > > And I believe that instead of > > > SPD_CUST we should get rid (or at least minimize) the problems with > > > BOTHER in user space. > > > > I looked into archives and seems that glibc people are not interested in > > this area. And I'm not going to spend time on another project which seems > > to be useless. > > So why should the kernel suffer if it already provides something good > for the user and user space ignores that? Because it is unusable? API which standard linux userspace applications cannot use is useless. And for application develop it does not matter if issue is in kernel part of API or userspace part of API. At the end would be use used. With whole this discussion I have feeling that there correct way is just to use SDP flags in userspace as there is no interest in fixing BOTHER's c_ospeed and c_ispeed in kernel drivers and it was rejected just because of not handling SDP flags correctly. > > > [1]: https://github.com/npat-efault/picocom/blob/master/termios2.txt > > > [2]: https://github.com/jmesmon/picocom/issues/2 > > -- > With Best Regards, > Andy Shevchenko
