[Top][All Lists]

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

Re: [PATCH v3 07/16] hw/i386/vmport: Introduce vmport.h

From: Liran Alon
Subject: Re: [PATCH v3 07/16] hw/i386/vmport: Introduce vmport.h
Date: Sat, 14 Mar 2020 14:13:17 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

On 14/03/2020 10:31, Philippe Mathieu-Daudé wrote:
On 3/13/20 11:38 PM, Liran Alon wrote:
On 13/03/2020 21:57, Philippe Mathieu-Daudé wrote:
On 3/12/20 5:54 PM, Liran Alon wrote:
No functional change. This is mere refactoring.

Suggested-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Liran Alon <address@hidden>
  hw/i386/pc.c             |  1 +
  hw/i386/vmmouse.c        |  1 +
  hw/i386/vmport.c         |  1 +
  include/hw/i386/pc.h     | 13 -------------
  include/hw/i386/vmport.h | 16 ++++++++++++++++

What about moving it to hw/i386/vmport.h (no under include/)?

Reviewed-by: Philippe Mathieu-Daudé <address@hidden>

Can you explain the logic that separates between hw/i386/*.h to include/hw/i386/*.h?

Headers in the include/hw/ namespace can be consumed by all machine targets.
But this doesn't seem true for headers in include/hw/i386/*.h...
It contains things that are target-specific. E.g. ioapic.h, x86-iommu.h, intel_iommu.h and etc. I still don't quite understand the separation between these directories. It seems both are i386-specific and one of them shouldn't exists.
If this is a target-specific device, having it local to the target (hw/i386/) protect generic code (and other targets) of using it. This helps detecting wrong dependencies between components.

If it makes sense, sure I will move it. I just don't know what is the convention here.

Michael/Paolo/Eduardo what do you recommend?

reply via email to

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