On Thu, Nov 21, 2019 at 8:12 PM Helge Deller <del...@gmx.de> wrote: > > On 21.11.19 19:23, Philippe Mathieu-Daudé wrote: > > On 11/21/19 6:35 PM, Aleksandar Markovic wrote: > >> On Thursday, November 21, 2019, Philippe Mathieu-Daudé <phi...@redhat.com > >> <mailto:phi...@redhat.com>> wrote: > >> > >> On 11/21/19 6:00 PM, Aleksandar Markovic wrote: > >> > >> On Thursday, November 21, 2019, Philippe Mathieu-Daudé > >> <phi...@redhat.com <mailto:phi...@redhat.com> > >> <mailto:phi...@redhat.com <mailto:phi...@redhat.com>>> wrote: > >> > >> On 11/21/19 9:19 AM, Helge Deller wrote: > >> > >> On 20.11.19 23:20, Aleksandar Markovic wrote: > >> > >> On Wed, Nov 20, 2019 at 10:13 PM Aleksandar Markovic > >> <aleksandar.m.m...@gmail.com > >> <mailto:aleksandar.m.m...@gmail.com> > >> <mailto:aleksandar.m.m...@gmail.com > >> <mailto:aleksandar.m.m...@gmail.com>>> wrote: > >> > >> > >> On Wed, Nov 20, 2019 at 3:58 PM Helge Deller > >> <del...@gmx.de <mailto:del...@gmx.de> > >> <mailto:del...@gmx.de <mailto:del...@gmx.de>>> wrote: > >> > >> > >> Improve strace output of various syscalls > >> which > >> either have none > >> or only int-type parameters. > >> > >> > >> It would be nice if you included a history of > >> the patch > >> (after the line > >> "---", as it is customary for single patch > >> submission). > >> You changed > >> only ioctl() in v2, right? > >> > >> > >> Yes. Will add history in next round. > >> > >> I missed your v2, but responded with several > >> hints to v1. > >> > >> > >> Yes, I saw all your mails. > >> Thanks for your feedback! > >> > >> userfaultfd(), membarrier(), mlock2()... - all could > >> be > >> included into > >> your patch. > >> > >> > >> I think there are quite some more which I didn't included. > >> That's why I wrote "*various*" and not "*all*" in my > >> changelog. > >> I'm debugging other code, and the ones I fixed are the > >> ones I > >> actually tested with my code. > >> > >> > >> If you don't have handy way to test the other syscalls, > >> I'll rather > >> restrict your patch to the one you tested, at least you are > >> certain > >> you didn't introduced regressions. Unless their > >> implementation is > >> trivial, of course. > >> > >> > >> What can be handier than writing a program that contains a > >> single system call? > >> > >> > >> Ahah very easy indeed :) Not noticing it shows how busy I am with > >> firmware world than I forgot linux-user can be a simpler/powerful > >> way to easily test stuff, as the Hexagon recent port also demonstrated. > >> > >> > >> Hexagon port doesn't have anything to do with this patch and didn't > >> demonstrate anything new wrt linux-user. I have no idea what you meant to > >> say. > > > > I simply meant to say, if your port can run linux-user binaries, it > > simplifies a lot the testing/coverage. > > > > Hexagon is simpler to test than AVR. > > > >> But, OK, Helge is the submitter, and he decides on the scope of his > >> patch. I am fine if he wants to limit it only to handful of > >> syscalls. I just hinted he could increase the vslue of the patch > >> significantly in an easy way. > Aleksandar, I really appreciate your feedback, but for now I'd like > to limit my patch to the currently implemented functions. > If you look in the file history you will find other submissions of > this type from me, so I'm sure I will follow up with further patches. > But right now I'm missing the time. > So, if it could be applied as is, it's a step forward for now. > I'll send a v3 patch shortly. >
Sure, I already said that I would certainly agree with that. However, I can't agree in a similar fashion with your another patch on signal names. This is since that patch in its present state puts MIPS in an inferior position. Yours, Aleksandar > Helge