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

Re: [PATCH v2 5/5] xen/common: move device initialization code to common code



On Mon, 2024-09-23 at 16:43 +0200, Jan Beulich wrote:
> On 17.09.2024 18:15, Oleksii Kurochko wrote:
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -12,6 +12,14 @@ config CORE_PARKING
> >     bool
> >     depends on NR_CPUS > 1
> >  
> > +config DEVICE_INIT
> > +   bool
> > +   default !X86
> 
> This can simply be "def_bool y" as ...
> 
> > +   depends on !X86 && (ACPI || HAS_DEVICE_TREE)
> 
> ... this enforces all restrictions. As indicated before I'd prefer if
> we
> could get away without yet another Kconfig constant, which would then
> also eliminate my concern about the expression not really covering
> for
> the case where x86 would obtain DT support (and hence likely needing
> the
> initialization here, too). What about ...
> 
> > --- a/xen/common/Makefile
> > +++ b/xen/common/Makefile
> > @@ -6,6 +6,7 @@ obj-$(CONFIG_HYPFS_CONFIG) += config_data.o
> >  obj-$(CONFIG_CORE_PARKING) += core_parking.o
> >  obj-y += cpu.o
> >  obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o
> > +obj-$(CONFIG_DEVICE_INIT) += device.o
> 
> obj-$(CONFIG_HAS_DEVICE_TREE) += device.o
> obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
> 
> ? (Eventually we could then simplify this to just obj-$(CONFIG_ACPI),
> to allow DT on x86, making sure the ACPI part of the file builds for
> x86 but does nothing there.)
I am okay with this solution. It seems I misunderstood you in the first
version of this patch series. When "obj-$(or ... )" was used, I decided
it wasn’t a good approach to use 'or', 'filter-out', or other similar
functions in Makefiles for such cases. I couldn't come up with a better
solution at the time, so I introduced a new config instead.

The only issue I see with this approach is that in device.c, there is
the following code:
   #ifdef CONFIG_ACPI
   
   extern const struct acpi_device_desc _asdevice[], _aedevice[];
   
   int __init acpi_device_init(enum device_class class, const void *data,
   int class_type)
      ...
   
   #endif
This shouldn't be compiled for X86. However, it will still be compiled
if we simplify to:
   obj-$(CONFIG_HAS_DEVICE_TREE) += device.o
   obj-$(CONFIG_ACPI) += device.o
The situation where we have CONFIG_HAS_DEVICE_TREE=y and CONFIG_ACPI=y
is possible ( if X86 will start or already using CONFIG_HAS_DEVICE_TREE
). The same will be if the second obj looks like: "obj-$(filter-out
$(CONFIG_X86),$(CONFIG_ACPI)) += device.o" and X86 will use
CONFIG_HAS_DEVICE_TREE.

To resolve this, we probably need two separate files: device-dt.c and
device-acpi.c, and then use:
   obj-$(CONFIG_HAS_DEVICE_TREE) += device-dt.o
   obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device-acpi.o

Alternatively, we could make an exception in device.c and add a
!CONFIG_X86 condition:
   #if defined(CONFIG_ACPI) && !defined(CONFIG_X86)
   extern const struct acpi_device_desc _asdevice[], _aedevice[];
   
   int __init acpi_device_init(enum device_class class, const void
   *data, int class_type)
   ...
   #endif

~ Oleksii



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.