On Tue, Jun 30, 2020 at 03:00:34PM +0200, Rafael J. Wysocki wrote: > On Tue, Jun 30, 2020 at 2:52 PM Greg Kroah-Hartman > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Tue, Jun 30, 2020 at 01:49:48PM +0300, Heikki Krogerus wrote: > > > On Mon, Jun 29, 2020 at 09:49:41PM -0700, Rajat Jain wrote: > > > > Add a new (optional) field to denote the physical location of a device > > > > in the system, and expose it in sysfs. This was discussed here: > > > > https://lore.kernel.org/linux-acpi/20200618184621.GA446639@xxxxxxxxx/ > > > > > > > > (The primary choice for attribute name i.e. "location" is already > > > > exposed as an ABI elsewhere, so settled for "site"). Individual buses > > > > that want to support this new attribute can opt-in by setting a flag in > > > > bus_type, and then populating the location of device while enumerating > > > > it. > > > > > > So why not just call it "physical_location"? > > > > That's better, and will allow us to put "3rd blue plug from the left, > > 4th row down" in there someday :) > > > > All of this is "relative" to the CPU, right? But what CPU? Again, how > > are the systems with drawers of PCI and CPUs and memory that can be > > added/removed at any point in time being handled here? What is > > "internal" and "external" for them? > > > > What exactly is the physical boundry here that is attempting to be > > described? > > Also, where is the "physical location" information going to come from? Who knows? :) Some BIOS seem to provide this, but do you trust that? > If that is the platform firmware (which I suspect is the anticipated > case), there may be problems with reliability related to that. s/may/will/ which means making the kernel inact a policy like this patch series tries to add, will result in a lot of broken systems, which is why I keep saying that it needs to be done in userspace. It's as if some of us haven't been down this road before and just keep being ignored... {sigh} greg k-h
