[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d0106281-f65c-369f-ef0f-11afc5f60048@gmail.com>
Date: Mon, 18 Nov 2019 18:18:23 +0100
From: Brice Goglin <brice.goglin@...il.com>
To: Dan Williams <dan.j.williams@...el.com>,
Jonathan Cameron <jonathan.cameron@...wei.com>
Cc: Tao Xu <tao3.xu@...el.com>, Linux MM <linux-mm@...ck.org>,
Linux ACPI <linux-acpi@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
X86 ML <x86@...nel.org>, Keith Busch <keith.busch@...el.com>,
Jérôme Glisse <jglisse@...hat.com>,
"Rafael J . Wysocki" <rjw@...ysocki.net>,
Linuxarm <linuxarm@...wei.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH V5 1/4] ACPI: Support Generic Initiator only domains
Le 16/11/2019 à 21:45, Dan Williams a écrit :
>
>> My feeling is that any existing users of access0 are definitely not going
>> to be expecting generic initiators, so we might want to do this the other
>> way around. access0 is only CPUs and memory, access1 is including
>> generic initiators. If there are no GIs don't expose access1 at all?
> There are no consumers of the information that I know of, so I do not
> see the risk of regression.
hwloc already reads access0/initiators/ node symlinks (mostly useful for
finding which CPUs are local to kmem dax devices). If I understand
correctly the changes you propose, we would get an empty list of CPUs in
the access0/initiators/ nodes? If it only occurs on platforms with GI
(when are those coming to market?), I'd say it's not a big deal for us,
we'll manage to have users upgrade their hwloc.
Brice
Powered by blists - more mailing lists