Message ID | 20231004090629.37473-1-philmd@linaro.org |
---|---|
Headers | show |
Series | misc: Rename 'softmmu' -> 'system' | expand |
On Wed, Oct 04, 2023 at 11:06:15AM +0200, Philippe Mathieu-Daudé wrote: > This series finishes the cleanup which remove the confusion > of using 'softmmu' when we really mean 'system emulation', > as opposition to 'user emulation'. Am I mis-understanding what you mean by 'finishes' here, as I see many references to softmmu remaining $ git grep softmmu | wc -l 270 In particular under configs/ I was also hoping it meant that we'd be changing configure to allow configure --target-list=x86_64-system though the lazy side of me would like configure --target-list=x86_64-vm for less typing > > Now that Richard posted its "tcg: Allow softmmu for user-only" > series, this is particularly relevant: > https://lore.kernel.org/qemu-devel/20231003174356.1602279-1-richard.henderson@linaro.org/ > > Philippe Mathieu-Daudé (13): > softmmu/trace-events: Fix a typo > travis-ci: Correct invalid mentions of 'softmmu' by 'system' > cpu: Correct invalid mentions of 'softmmu' by 'system-mode' > fuzz: Correct invalid mentions of 'softmmu' by 'system' > tcg: Correct invalid mentions of 'softmmu' by 'system-mode' > accel: Rename accel_softmmu* -> accel_system* > gdbstub: Rename 'softmmu' -> 'system' > semihosting: Rename softmmu_FOO_user() -> uaccess_FOO_user() > target/i386: Rename i386_softmmu_kvm_ss -> i386_kvm_ss > hw/virtio/meson: Rename softmmu_virtio_ss -> system_virtio_ss > meson: Rename softmmu_mods -> system_mods > meson: Rename target_softmmu_arch -> target_system_arch > system: Rename softmmu/ directory as system/ > > MAINTAINERS | 44 +++++++++---------- > docs/devel/build-system.rst | 4 +- > docs/devel/qtest.rst | 2 +- > docs/devel/testing.rst | 2 +- > tests/tcg/s390x/pgm-specification.mak | 2 +- > meson.build | 22 +++++----- > accel/{accel-softmmu.h => accel-system.h} | 6 +-- > gdbstub/internals.h | 4 +- > include/qemu/atomic128.h | 4 +- > .../{softmmu-uaccess.h => uaccess.h} | 24 +++++----- > include/sysemu/runstate-action.h | 2 +- > include/tcg/tcg-op-common.h | 2 +- > softmmu/trace.h | 1 - > {softmmu => system}/timers-state.h | 0 > system/trace.h | 1 + > tests/qtest/fuzz/fuzz.h | 4 +- > accel/accel-common.c | 2 +- > accel/{accel-softmmu.c => accel-system.c} | 6 +-- > accel/tcg/user-exec.c | 2 +- > cpu.c | 2 +- > gdbstub/{softmmu.c => system.c} | 2 +- > hw/core/cpu-common.c | 4 +- > semihosting/arm-compat-semi.c | 4 +- > semihosting/config.c | 2 +- > semihosting/guestfd.c | 2 +- > semihosting/syscalls.c | 2 +- > semihosting/uaccess.c | 14 +++--- > stubs/semihost.c | 4 +- > {softmmu => system}/arch_init.c | 0 > {softmmu => system}/async-teardown.c | 0 > {softmmu => system}/balloon.c | 0 > {softmmu => system}/bootdevice.c | 0 > {softmmu => system}/cpu-throttle.c | 0 > {softmmu => system}/cpu-timers.c | 0 > {softmmu => system}/cpus.c | 0 > {softmmu => system}/datadir.c | 0 > {softmmu => system}/device_tree.c | 0 > {softmmu => system}/dirtylimit.c | 0 > {softmmu => system}/dma-helpers.c | 0 > {softmmu => system}/globals.c | 0 > {softmmu => system}/icount.c | 0 > {softmmu => system}/ioport.c | 0 > {softmmu => system}/main.c | 0 > {softmmu => system}/memory.c | 2 +- > {softmmu => system}/memory_mapping.c | 0 > {softmmu => system}/physmem.c | 6 ++- > {softmmu => system}/qdev-monitor.c | 0 > {softmmu => system}/qemu-seccomp.c | 0 > {softmmu => system}/qtest.c | 0 > {softmmu => system}/rtc.c | 0 > {softmmu => system}/runstate-action.c | 0 > {softmmu => system}/runstate-hmp-cmds.c | 0 > {softmmu => system}/runstate.c | 0 > {softmmu => system}/tpm-hmp-cmds.c | 0 > {softmmu => system}/tpm.c | 0 > {softmmu => system}/vl.c | 0 > {softmmu => system}/watchpoint.c | 0 > target/m68k/m68k-semi.c | 2 +- > target/mips/tcg/sysemu/mips-semi.c | 2 +- > target/nios2/nios2-semi.c | 2 +- > target/riscv/vector_helper.c | 2 +- > tcg/region.c | 4 +- > tcg/tcg.c | 11 ++--- > tests/qtest/fuzz/fuzz.c | 2 +- > tests/tcg/multiarch/system/memory.c | 4 +- > tcg/aarch64/tcg-target.c.inc | 4 +- > tcg/arm/tcg-target.c.inc | 2 +- > tcg/i386/tcg-target.c.inc | 2 +- > tcg/loongarch64/tcg-target.c.inc | 4 +- > tcg/mips/tcg-target.c.inc | 4 +- > tcg/ppc/tcg-target.c.inc | 4 +- > tcg/riscv/tcg-target.c.inc | 4 +- > tcg/s390x/tcg-target.c.inc | 4 +- > tcg/sparc64/tcg-target.c.inc | 4 +- > .travis.yml | 4 +- > accel/meson.build | 2 +- > accel/stubs/meson.build | 10 ++--- > gdbstub/meson.build | 10 ++--- > gdbstub/trace-events | 2 +- > hw/virtio/meson.build | 22 +++++----- > scripts/checkpatch.pl | 2 +- > scripts/coverity-scan/COMPONENTS.md | 2 +- > scripts/get_maintainer.pl | 2 +- > {softmmu => system}/meson.build | 0 > {softmmu => system}/trace-events | 2 +- > target/alpha/meson.build | 2 +- > target/arm/meson.build | 2 +- > target/avr/meson.build | 2 +- > target/cris/meson.build | 2 +- > target/hppa/meson.build | 2 +- > target/i386/kvm/meson.build | 10 ++--- > target/i386/meson.build | 2 +- > target/loongarch/meson.build | 2 +- > target/m68k/meson.build | 2 +- > target/microblaze/meson.build | 2 +- > target/mips/meson.build | 2 +- > target/nios2/meson.build | 2 +- > target/openrisc/meson.build | 2 +- > target/ppc/meson.build | 2 +- > target/riscv/meson.build | 2 +- > target/rx/meson.build | 2 +- > target/s390x/meson.build | 2 +- > target/sh4/meson.build | 2 +- > target/sparc/meson.build | 2 +- > target/tricore/meson.build | 2 +- > target/xtensa/meson.build | 2 +- > tcg/meson.build | 6 +-- > tests/tcg/Makefile.target | 2 +- > tests/tcg/multiarch/gdbstub/interrupt.py | 2 +- > tests/tcg/multiarch/gdbstub/memory.py | 2 +- > tests/tcg/s390x/pgm-specification-softmmu.S | 2 +- > tests/tcg/s390x/softmmu.ld | 2 +- > tests/tcg/xtensa/Makefile.softmmu-target | 2 +- > tests/tcg/xtensaeb/Makefile.softmmu-target | 2 +- > tests/unit/meson.build | 2 +- > 115 files changed, 188 insertions(+), 181 deletions(-) > rename accel/{accel-softmmu.h => accel-system.h} (77%) > rename include/semihosting/{softmmu-uaccess.h => uaccess.h} (75%) > delete mode 100644 softmmu/trace.h > rename {softmmu => system}/timers-state.h (100%) > create mode 100644 system/trace.h > rename accel/{accel-softmmu.c => accel-system.c} (96%) > rename gdbstub/{softmmu.c => system.c} (99%) > rename {softmmu => system}/arch_init.c (100%) > rename {softmmu => system}/async-teardown.c (100%) > rename {softmmu => system}/balloon.c (100%) > rename {softmmu => system}/bootdevice.c (100%) > rename {softmmu => system}/cpu-throttle.c (100%) > rename {softmmu => system}/cpu-timers.c (100%) > rename {softmmu => system}/cpus.c (100%) > rename {softmmu => system}/datadir.c (100%) > rename {softmmu => system}/device_tree.c (100%) > rename {softmmu => system}/dirtylimit.c (100%) > rename {softmmu => system}/dma-helpers.c (100%) > rename {softmmu => system}/globals.c (100%) > rename {softmmu => system}/icount.c (100%) > rename {softmmu => system}/ioport.c (100%) > rename {softmmu => system}/main.c (100%) > rename {softmmu => system}/memory.c (99%) > rename {softmmu => system}/memory_mapping.c (100%) > rename {softmmu => system}/physmem.c (99%) > rename {softmmu => system}/qdev-monitor.c (100%) > rename {softmmu => system}/qemu-seccomp.c (100%) > rename {softmmu => system}/qtest.c (100%) > rename {softmmu => system}/rtc.c (100%) > rename {softmmu => system}/runstate-action.c (100%) > rename {softmmu => system}/runstate-hmp-cmds.c (100%) > rename {softmmu => system}/runstate.c (100%) > rename {softmmu => system}/tpm-hmp-cmds.c (100%) > rename {softmmu => system}/tpm.c (100%) > rename {softmmu => system}/vl.c (100%) > rename {softmmu => system}/watchpoint.c (100%) > rename {softmmu => system}/meson.build (100%) > rename {softmmu => system}/trace-events (99%) > > -- > 2.41.0 > > With regards, Daniel
On 04/10/2023 14.33, Daniel P. Berrangé wrote: > On Wed, Oct 04, 2023 at 11:06:15AM +0200, Philippe Mathieu-Daudé wrote: >> This series finishes the cleanup which remove the confusion >> of using 'softmmu' when we really mean 'system emulation', >> as opposition to 'user emulation'. > > Am I mis-understanding what you mean by 'finishes' here, as > I see many references to softmmu remaining > > $ git grep softmmu | wc -l > 270 > > In particular under configs/ > > I was also hoping it meant that we'd be changing configure > to allow > > configure --target-list=x86_64-system > > though the lazy side of me would like > > configure --target-list=x86_64-vm > > for less typing Maybe we should also bikeshed about the naming first... "system" is a quite overloaded word in this context already, and "vm" sounds rather like hardware-accelerated stuff ... what about using something like "sysemu"? Or "fullsys" for "full system emulation" (in contrast to "user space"-only emulation)? Thomas
On Wed, Oct 04, 2023 at 02:37:14PM +0200, Thomas Huth wrote: > On 04/10/2023 14.33, Daniel P. Berrangé wrote: > > On Wed, Oct 04, 2023 at 11:06:15AM +0200, Philippe Mathieu-Daudé wrote: > > > This series finishes the cleanup which remove the confusion > > > of using 'softmmu' when we really mean 'system emulation', > > > as opposition to 'user emulation'. > > > > Am I mis-understanding what you mean by 'finishes' here, as > > I see many references to softmmu remaining > > > > $ git grep softmmu | wc -l > > 270 > > > > In particular under configs/ > > > > I was also hoping it meant that we'd be changing configure > > to allow > > > > configure --target-list=x86_64-system > > > > though the lazy side of me would like > > > > configure --target-list=x86_64-vm > > > > for less typing > > Maybe we should also bikeshed about the naming first... "system" is a quite > overloaded word in this context already, and "vm" sounds rather like > hardware-accelerated stuff ... what about using something like "sysemu"? Or > "fullsys" for "full system emulation" (in contrast to "user space"-only > emulation)? Simply 'machine' feels like an option, to avoid suggesting a bias towards either virtualization or emulation. With regards, Daniel
Queued, thanks. Paolo
On 04/10/2023 15.20, Paolo Bonzini wrote:
> Queued, thanks.
Ok, but could you please wait with a pull request for a day or two to see
whether we could agree on a better wording first:
https://lore.kernel.org/qemu-devel/85be2979-c0ca-3eb4-dae9-bbabf256c201@redhat.com/
?
Thomas
On 10/4/23 14:37, Thomas Huth wrote: > On 04/10/2023 14.33, Daniel P. Berrangé wrote: >> On Wed, Oct 04, 2023 at 11:06:15AM +0200, Philippe Mathieu-Daudé wrote: >>> This series finishes the cleanup which remove the confusion >>> of using 'softmmu' when we really mean 'system emulation', >>> as opposition to 'user emulation'. >> >> Am I mis-understanding what you mean by 'finishes' here, as >> I see many references to softmmu remaining >> >> $ git grep softmmu | wc -l >> 270 >> >> In particular under configs/ >> >> I was also hoping it meant that we'd be changing configure >> to allow >> >> configure --target-list=x86_64-system >> >> though the lazy side of me would like >> >> configure --target-list=x86_64-vm >> >> for less typing > > Maybe we should also bikeshed about the naming first... "system" is a quite > overloaded word in this context already, and "vm" sounds rather like > hardware-accelerated stuff ... what about using something like "sysemu"? Or > "fullsys" for "full system emulation" (in contrast to "user space"-only > emulation)? > > Thomas > > Just my 2c, to me "system" is the only word that makes sense here, even from a purely user perspective. We already have exposed "system" to the user as a way to mean this, as in: ./configure --enable-system ./configure --disable-system and if everything is renamed from softmmu to system where it makes sense in the code, it's the best option for development as well in my view. Thanks, Claudio
On Wed, Oct 4, 2023 at 3:41 PM Claudio Fontana <cfontana@suse.de> wrote: > > On 10/4/23 14:37, Thomas Huth wrote: > > On 04/10/2023 14.33, Daniel P. Berrangé wrote: > >> Am I mis-understanding what you mean by 'finishes' here, as > >> I see many references to softmmu remaining > >> In particular under configs/ > >> > >> I was also hoping it meant that we'd be changing configure > >> to allow > >> > >> configure --target-list=x86_64-system > >> configure --target-list=x86_64-vm > >> > >> for less typing > > > > Maybe we should also bikeshed about the naming first... "system" is a quite > > overloaded word in this context already, and "vm" sounds rather like > > hardware-accelerated stuff ... what about using something like "sysemu"? Or > > "fullsys" for "full system emulation" (in contrast to "user space"-only > > emulation)? I agree that changing other remnants should be done right after this patch, for example $softmmu in configure. Changing all targets is a very large and very user-visible change, it is required but it should be planned very well. As to the actual target names, I think system is the only consistent choice since we have --enable/--disable-system (as pointed out by Claudio) and qemu-system-*. sysemu may make a little more sense in the codebase (we have include/sysemu after all), but maybe that ship has sailed since we have many occurrences of "system", for example system_ss and other related sourcesets. Paolo
On Wed, Oct 04, 2023 at 03:49:31PM +0200, Paolo Bonzini wrote: > On Wed, Oct 4, 2023 at 3:41 PM Claudio Fontana <cfontana@suse.de> wrote: > > > > On 10/4/23 14:37, Thomas Huth wrote: > > > On 04/10/2023 14.33, Daniel P. Berrangé wrote: > > >> Am I mis-understanding what you mean by 'finishes' here, as > > >> I see many references to softmmu remaining > > >> In particular under configs/ > > >> > > >> I was also hoping it meant that we'd be changing configure > > >> to allow > > >> > > >> configure --target-list=x86_64-system > > >> configure --target-list=x86_64-vm > > >> > > >> for less typing > > > > > > Maybe we should also bikeshed about the naming first... "system" is a quite > > > overloaded word in this context already, and "vm" sounds rather like > > > hardware-accelerated stuff ... what about using something like "sysemu"? Or > > > "fullsys" for "full system emulation" (in contrast to "user space"-only > > > emulation)? > > I agree that changing other remnants should be done right > after this patch, for example $softmmu in configure. Changing > all targets is a very large and very user-visible change, it is > required but it should be planned very well. > > As to the actual target names, I think system is the only > consistent choice since we have --enable/--disable-system > (as pointed out by Claudio) and qemu-system-*. sysemu > may make a little more sense in the codebase (we have > include/sysemu after all), but maybe that ship has sailed > since we have many occurrences of "system", for example > system_ss and other related sourcesets. Yep, I agree with that view now, lets stick with 'system'. With regards, Daniel
On 4/10/23 15:49, Paolo Bonzini wrote: > On Wed, Oct 4, 2023 at 3:41 PM Claudio Fontana <cfontana@suse.de> wrote: >> >> On 10/4/23 14:37, Thomas Huth wrote: >>> On 04/10/2023 14.33, Daniel P. Berrangé wrote: >>>> Am I mis-understanding what you mean by 'finishes' here, as >>>> I see many references to softmmu remaining >>>> In particular under configs/ >>>> >>>> I was also hoping it meant that we'd be changing configure >>>> to allow >>>> >>>> configure --target-list=x86_64-system >>>> configure --target-list=x86_64-vm >>>> >>>> for less typing >>> >>> Maybe we should also bikeshed about the naming first... "system" is a quite >>> overloaded word in this context already, and "vm" sounds rather like >>> hardware-accelerated stuff ... what about using something like "sysemu"? Or >>> "fullsys" for "full system emulation" (in contrast to "user space"-only >>> emulation)? > > I agree that changing other remnants should be done right > after this patch, for example $softmmu in configure. Changing > all targets is a very large and very user-visible change, it is > required but it should be planned very well. As usual I should have been more verbose in my cover. This series focus on the C code (and travis) to avoid misuse of 'softmmu'. Yes I agree it would be nice to also rename the binaries, but this is a buildsys change (even if we use symlinks/aliases for some deprecation period). This is not a tiny patch, and requires thoughts. On one hand I'd rather not rush renaming binaries -- annoying users -- without a clear long term plan (which I'm not clear about). On another hand I wouldn't delay Richard user-mode work. Renaming binaries seems orthogonal to me, and could be done later IMO. > As to the actual target names, I think system is the only > consistent choice since we have --enable/--disable-system > (as pointed out by Claudio) and qemu-system-*. sysemu > may make a little more sense in the codebase (we have > include/sysemu after all), but maybe that ship has sailed > since we have many occurrences of "system", for example > system_ss and other related sourcesets. > > Paolo >
On 04/10/2023 15.53, Daniel P. Berrangé wrote: > On Wed, Oct 04, 2023 at 03:49:31PM +0200, Paolo Bonzini wrote: >> On Wed, Oct 4, 2023 at 3:41 PM Claudio Fontana <cfontana@suse.de> wrote: >>> >>> On 10/4/23 14:37, Thomas Huth wrote: >>>> On 04/10/2023 14.33, Daniel P. Berrangé wrote: >>>>> Am I mis-understanding what you mean by 'finishes' here, as >>>>> I see many references to softmmu remaining >>>>> In particular under configs/ >>>>> >>>>> I was also hoping it meant that we'd be changing configure >>>>> to allow >>>>> >>>>> configure --target-list=x86_64-system >>>>> configure --target-list=x86_64-vm >>>>> >>>>> for less typing >>>> >>>> Maybe we should also bikeshed about the naming first... "system" is a quite >>>> overloaded word in this context already, and "vm" sounds rather like >>>> hardware-accelerated stuff ... what about using something like "sysemu"? Or >>>> "fullsys" for "full system emulation" (in contrast to "user space"-only >>>> emulation)? >> >> I agree that changing other remnants should be done right >> after this patch, for example $softmmu in configure. Changing >> all targets is a very large and very user-visible change, it is >> required but it should be planned very well. >> >> As to the actual target names, I think system is the only >> consistent choice since we have --enable/--disable-system >> (as pointed out by Claudio) and qemu-system-*. sysemu >> may make a little more sense in the codebase (we have >> include/sysemu after all), but maybe that ship has sailed >> since we have many occurrences of "system", for example >> system_ss and other related sourcesets. > > Yep, I agree with that view now, lets stick with 'system'. Ok, convinced, seems like 'system' is likely still the best choice. Thomas