Re: [PATCH v2] linux-user/strace: Improve output of various syscalls

[Aleksandar Markovic]

On Thu, Nov 21, 2019 at 8:12 PM Helge Deller <address@hidden> 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é <address@hidden 
> >> <mailto:address@hidden>> wrote:
> >>
> >>     On 11/21/19 6:00 PM, Aleksandar Markovic wrote:
> >>
> >>         On Thursday, November 21, 2019, Philippe Mathieu-Daudé
> >>         <address@hidden <mailto:address@hidden>
> >>         <mailto:address@hidden <mailto:address@hidden>>> 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
> >>                      <address@hidden
> >>         <mailto:address@hidden>
> >>                      <mailto:address@hidden
> >>         <mailto:address@hidden>>> wrote:
> >>
> >>
> >>                          On Wed, Nov 20, 2019 at 3:58 PM Helge Deller
> >>                          <address@hidden <mailto:address@hidden>
> >>         <mailto:address@hidden <mailto:address@hidden>>> 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