lkml.org 
[lkml]   [2020]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 5/7] driver core: Add device location to "struct device" and expose it in sysfs
    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@linuxfoundation.org> 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@kroah.com/
    > > > >
    > > > > (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

    \
     
     \ /
      Last update: 2020-06-30 17:38    [W:4.009 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site