linux-kernel - Re: [PATCH] [RFC] Expose _SUN in /proc/acpi/processor/<...>/info

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20071213190801.GA7747@ldl.fc.hp.com>
Date:	Thu, 13 Dec 2007 12:08:02 -0700
From:	Alex Chiang <achiang@...com>
To:	Len Brown <lenb@...nel.org>
Cc:	akpm@...ux-foundation.org, linux-acpi <linux-acpi@...r.kernel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [RFC] Expose _SUN in /proc/acpi/processor/<...>/info

Hi Len,

* Len Brown <lenb@...nel.org>:
> On Tuesday 30 October 2007 19:50, Alex Chiang wrote:
> > 
> > I'm looking for comments on the following patch that exposes _SUN
> > on processor objects in /proc/acpi/processor/<...>/info. 
> > 
> > This didn't get many comments on the linux-acpi list, so I'm
> > sending to a wider distribution.
> > 
> > I notice that acpiphp exposes _SUN for (hotpluggable) PCI slots
> > in /sys/bus/pci/slots/N/, where N is the value of _SUN. I'm not
> > so sure we want to go *exactly* in the same direction for CPUs,
> > because:
> > 
> >   - x86 systems might not implement _SUN for processors
> >   - ia64 systems that implement ACPI 2.x do not have unique
> >     values for _SUN across the entire system
> > 
> > Nonetheless, even non-unique values of _SUN are still helpful for
> > userspace to figure out which physical socket a CPU might be in,
> > especially when combined with information from /proc/cpuinfo.
> > 
> > Thoughts?
> 
> We've not allowed new features in /proc/acpi
> since we started removing /proc/acpi.
> ie. we don't want to update the API, we want to delete it.
 
Ok.

> If this is a useful thing for user-space to know, then you need
> to figure out a generic way to present it -- likely under
> /sys/devices/system/cpu/
 
There are lots of ways to go with this, and I'd like to get an
idea of what you think makes most sense before going off and
spending tons of time here.

I see possible choices as:

  1) create something like:
  
	/sys/devices/system/cpu/cpuN/topology/socket_id

     And leave it up to the arch to figure if/how they want to
     implement it. On ia64 systems, we can get this information
     from the _SUN method.

  2) create something like:

  	/sys/devices/system/cpu/cpuN/acpi/

     And port over the stuff from /proc/acpi, adding in a new
     field for _SUN.

Thoughts?

Thanks.

/ac

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/