On Fri, Jul 8, 2022 at 6:25 PM Pali Rohár <pali@xxxxxxxxxx> wrote: > > 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"... Ask someone who makes a decision. I wrote just my p.o.v. on the "problem". I think there is no problem with SPD_CUST, it should be oblivionized. > > > > > > 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)." I do not know the "manpages git" URL. Neither its hosting. kernel.org? And then? It took time for you to just write something instead of helping me. Whatever. I found the commits. > 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. Then help make it happen? > 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. I'm puzzled who asked you about SPD_CUST implementation... It.is.an.ugly.hack. -- With Best Regards, Andy Shevchenko
