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

Re: [PATCH v2 01/15] xen: Clean up asm-generic/device.h


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Alejandro Vallejo <agarciav@xxxxxxx>
  • Date: Fri, 6 Jun 2025 12:21:32 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=e9VZL+7u7O0wdQzIObCKnPDKU6jDyEgg825DwfufhCI=; b=uYnfU7n9F1Tj8SuuQpkmOsfX89DSy6STxZThamSxEdrkX6V4fwD9PEffD+ZevVX8xN394liZUo5UxbHv80kDZ/iohSqFt6v77w0cj7HoTOQJDoiVF3mJTyJWMSZvOW1RgHV7vhPuQLkiXk2/t8jjveNUeLNtPSwkokCdEzxEdWGKkOqp40lF2sAuLf52Wtz3t7viiPojPV2u2dNakHEMUsWuJj7lAj6L+Oeq9ZRDQPwzftbzQ+yom+NsasgHMK70+OLTwof/qz417mHF/UjtHJdqG2fG5+JRWQfGY9NUbuzgW5vmO2/tF5ptGOioefOQHqGk63P571+qneH6WCvKHw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mNubjrCPpIv+4+oKumy4iBnED8LUiZTSeWZrS/F1EQ7jxIPNHmAMCCaLn3TwgJC2AHreYy2L7xVs+xG7D8xdAz1Z51OUMRpmBUA+s6zZN+OC4zjIOGZRBtG2Sxr5g138Dh6ShxcI9d3D3nm5LQ3tAplT90rF/118Qh9rn9HiuXBJpkAhY+OjIHhTbSABQgytjiEKKZrVE1DmVMvU4W+/I+rEqoc+0ZF9lf5TKJlWCLpZ8T5AUUSOznrLPxki/Z5SgxwuwcSl7oA6VZLLV2+NdVR1QkX4MutLggHlzF64GrUiPDsHLzg5HpSwSs8jlHtOekIR9JipVClZAlpgzaCH3Q==
  • Cc: Alistair Francis <alistair.francis@xxxxxxx>, Bob Eshleman <bobbyeshleman@xxxxxxxxx>, Connor Davis <connojdavis@xxxxxxxxx>, "Oleksii Kurochko" <oleksii.kurochko@xxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 06 Jun 2025 10:22:02 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri Jun 6, 2025 at 12:03 PM CEST, Jan Beulich wrote:
> On 06.06.2025 11:55, Alejandro Vallejo wrote:
>> On Fri Jun 6, 2025 at 8:51 AM CEST, Jan Beulich wrote:
>>> On 05.06.2025 21:47, Alejandro Vallejo wrote:
>>>> --- a/xen/include/asm-generic/device.h
>>>> +++ b/xen/include/asm-generic/device.h
>>>> @@ -1,14 +1,20 @@
>>>>  /* SPDX-License-Identifier: GPL-2.0-only */
>>>> +/*
>>>> + * This header helps DTB-based architectures abstract away where a 
>>>> particular
>>>> + * device came from, be it the DTB itself or enumerated on a PCI bus.
>>>> + */
>>>>  #ifndef __ASM_GENERIC_DEVICE_H__
>>>>  #define __ASM_GENERIC_DEVICE_H__
>>>>  
>>>> +#ifndef CONFIG_HAS_DEVICE_TREE
>>>> +#error "Header for exclusive use of DTB-based architectures"
>>>> +#endif
>>>> +
>>>>  #include <xen/stdbool.h>
>>>>  
>>>>  enum device_type
>>>>  {
>>>> -#ifdef CONFIG_HAS_DEVICE_TREE
>>>>      DEV_DT,
>>>> -#endif
>>>>      DEV_PCI
>>>>  };
>>>
>>> My objection to these changes remains; as a generic header it ought to be 
>>> what
>>> that attribute says - generic.
>> 
>> It is generic for any architecture where platform DTs exist (that is, 
>> anything
>> but x86).
>
> Here you're limiting things to what Xen presently "knows". I'm sure there are
> other architectures where DT is entirely unknown.

You'll struggle a lot to find one such arch unless you want to revive the
itanium port, and even then itanium would simply re-use x86's asm override.

>
> Furthermore isn't the work here part of the hyperlaunch effort, where DT will
> be introduced to x86? Hence "anything but" isn't quite right either then.
>
> Jan

Not a general DTB, no. A DTB defines the platform (in the same vein as a ACPI/
DSDT), with all platform devices enumerated there. x86 will not get any of that.

Without devices defined in the DTB, my original point still stands.

In general, if you don't have DT devices you typedef device_t to pci_dev to
avoid these wrappers altogether, and if you do you don't and the ifdef guards
stop having meaning.

If you remain unconvinced and others don't pitch in I'll just drop it from v3.
As I said, it's not essential.

Cheers,
Alejandro



 


Rackspace

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