qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/3] cpu: Forward-declare user-mode TaskState structure


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH 2/3] cpu: Forward-declare user-mode TaskState structure
Date: Thu, 4 Mar 2021 17:47:48 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0

On 3/4/21 4:26 PM, Philippe Mathieu-Daudé wrote:
> The TaskState structure is only used by user emulation.
> Currently it is hold in CPUState as a void pointer and
> casted in user-specific code. In order to simplify by
> - renaming this generic field
> - remove the casts
> in the next commit, forward-declare the type in "cpu.h".
> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>  bsd-user/qemu.h       | 4 ++--
>  include/hw/core/cpu.h | 7 +++++--
>  linux-user/qemu.h     | 4 ++--
>  3 files changed, 9 insertions(+), 6 deletions(-)

> diff --git a/include/hw/core/cpu.h b/include/hw/core/cpu.h
> index c005d3dc2d8..f4d2169cc8e 100644
> --- a/include/hw/core/cpu.h
> +++ b/include/hw/core/cpu.h
> @@ -274,6 +274,9 @@ struct qemu_work_item;
>  #define CPU_UNSET_NUMA_NODE_ID -1
>  #define CPU_TRACE_DSTATE_MAX_EVENTS 32
>  
> +/* See bsd-user/qemu.h and linux-user/qemu.h */
> +typedef struct TaskState TaskState;
> +
>  /**
>   * CPUState:
>   * @cpu_index: CPU index (informative).
> @@ -310,7 +313,7 @@ struct qemu_work_item;
>   * @gdb_num_regs: Number of total registers accessible to GDB.
>   * @gdb_num_g_regs: Number of registers in GDB 'g' packets.
>   * @next_cpu: Next CPU sharing TB cache.
> - * @opaque: User data.
> + * @opaque: User task data.
>   * @mem_io_pc: Host Program Counter at which the memory was accessed.
>   * @kvm_fd: vCPU file descriptor for KVM.
>   * @work_mutex: Lock to prevent multiple access to @work_list.
> @@ -386,7 +389,7 @@ struct CPUState {
>      QTAILQ_HEAD(, CPUWatchpoint) watchpoints;
>      CPUWatchpoint *watchpoint_hit;
>  
> -    void *opaque;
> +    TaskState *opaque;

FYI Paolo said on IRC:

"having multiple definition of the same type is not very good taste,
void* or union are both better".



reply via email to

[Prev in Thread] Current Thread [Next in Thread]