Re: [PULL 00/15] Renesas hardware patches for 2020-06-21

[Aleksandar Markovic]

понедељак, 22. јун 2020., Philippe Mathieu-Daudé <f4bug@amsat.org> је написао/ла:
> Hi Aleksandar,
>
> On 6/22/20 7:30 PM, Aleksandar Markovic wrote:
> > понедељак, 22. јун 2020., Aleksandar Markovic
> > <aleksandar.qemu.devel@gmail.com
> > <mailto:aleksandar.qemu.devel@gmail.com>> је написао/ла:
> > 
> > 
> > 
> >     понедељак, 22. јун 2020., Philippe Mathieu-Daudé <f4bug@amsat.org
> >     <mailto:f4bug@amsat.org>> је написао/ла:
> > 
> >         +Thomas
> > 
> >         On 6/22/20 6:19 PM, Peter Maydell wrote:
> >         > On Mon, 22 Jun 2020 at 17:01, Peter Maydell
> >         <peter.maydell@linaro.org <mailto:peter.maydell@linaro.org>> wrote:
> >         >>
> >         >> On Sun, 21 Jun 2020 at 13:50, Philippe Mathieu-Daudé
> >         <f4bug@amsat.org <mailto:f4bug@amsat.org>> wrote:
> >         >>> Renesas hardware patches
> >         >>>
> >         >>> - Add a common entry for Renesas hardware in MAINTAINERS
> >         >>> - Trivial SH4 cleanups
> >         >>> - Add RX GDB simulator from Yoshinori Sato
> >         >>>
> > 
> > 
> > 
> >     Can this rx patch be included in this pull request: (it was r-b-ed a
> >     couple of weeks ago already):
> > 
> >     https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg08581.html
> >     <https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg08581.html>
>
> This pull request only contains hardware emulation patches (files under
> hw/, not the TCG code from target/).

The patch in question affects system mode, therefore hardware emulation too. Not a big deal, but, to me, it seems as a natural part of this pull request. It is quite common that pull requests are not limited by directories - optimally, they should deal with certain set of related functionalities, not limited by directories. Why would be that patch be left lonesome? Could you please, Philippe, reconsider exclusion/inclusion of this patch, if possible?

Thanks, Aleksandar

> > R-b by Richard is here:
> > 
> > https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg00229.html
> > 
> > The two messages are not directly connected on the list, since r-b was
> > in June, and the patch was in May.
> > 
> >  
> > 
> >     Thanks in advance!
> > 
> >     Aleksandar
> > 
> > 
> >      
> > 
> >         >>> The Renesas RX target emulation was added in commit c8c35e5f51,
> >         >>> these patches complete the target by adding the hardware
> >         emulation.
> >         >>>
> >         >>> Thank you Yoshinori for adding this code to QEMU, and your
> >         patience
> >         >>> during the review process. Now your port is fully integrated.
> >         >>>
> >         >>> Travis-CI:
> >         >>> https://travis-ci.org/github/philmd/qemu/builds/700461815
> >         <https://travis-ci.org/github/philmd/qemu/builds/700461815>
> >         >>
> >         >> Hi; I'm afraid there's a format-string issue here (manifests
> >         >> on OSX, openbsd, and 32-bit platforms):
> >         >>
> >         >> /home/peter.maydell/qemu/hw/rx/rx-gdbsim.c: In function
> >         'rx_gdbsim_init':
> >         >> /home/peter.maydell/qemu/hw/rx/rx-gdbsim.c:93:22: error:
> >         format '%lli'
> >         >> expects argument of type 'long long int', but argument 2 has type
> >         >> 'ram_addr_t {aka unsigned int}' [-Werror=format=]
> >         >>          error_report("Invalid RAM size, should be more than
> >         %" PRIi64 " Bytes",
> >         >>                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >         >>                       mc->default_ram_size);
> >         >>                       ~~~~~~~~~~~~~~~~~~~~
> >         >
> >         > Also there appears to be a makefile/dependency bug somewhere,
> >         > because when I drop this merge attempt and retry building
> >         > with current master I get this error:
> >         >
> >         > make[1]: Entering directory '/home/petmay01/qemu-for-merges/slirp'
> >         > make[1]: Nothing to be done for 'all'.
> >         > make[1]: Leaving directory '/home/petmay01/qemu-for-merges/slirp'
> >         >   CC      qga/main.o
> >         >   CC      qemu-io.o
> >         >   CC      monitor/qmp-cmds-control.o
> >         > make: *** No rule to make target
> >         > '/home/petmay01/qemu-for-merges/hw/rx/Kconfig', needed by
> >         > 'aarch64-softmmu/config-devices.mak'.  Stop.
> >         > make: *** Waiting for unfinished jobs....
> >         > make: Leaving directory '/home/petmay01/qemu-for-merges/build/w64'
> >         >
> >         > This seems to be because aarch64-softmmu/config-devices.mak.d
> >         > in the build tree says that aarch64-softmmu/config-devices.mak
> >         > depends on all the Kconfig files; this means that if a Kconfig
> >         > file gets deleted then incremental build stops working?
> > 
> >         This seems the same problem previously discussed here:
> >         https://www.mail-archive.com/qemu-devel@nongnu.org/msg676319.html <https://www.mail-archive.com/qemu-devel@nongnu.org/msg676319.html>
> >