From: Alex Chiang <achiang@hp.com>
To: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: "hpa@zytor.com" <hpa@zytor.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"andi@firstfloor.org" <andi@firstfloor.org>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: add /proc/cpuinfo/physical id quirks
Date: Thu, 20 Aug 2009 14:54:25 -0600 [thread overview]
Message-ID: <20090820205425.GF13061@ldl.fc.hp.com> (raw)
In-Reply-To: <1250794594.2754.10.camel@sbs-t61.sc.intel.com>
* Suresh Siddha <suresh.b.siddha@intel.com>:
> On Wed, 2009-08-19 at 14:02 -0700, Alex Chiang wrote:
> > I agree with you (although I thought that they should be
> > 0-based) but this quirk addresses a specific platform, where
> > I can assume certain things about the BIOS, etc.
>
> What happens if for some reason, newer bios/newer cpu
> generations on this platform start having holes in the physical
> id space? We can't rule out these kind of changes and we don't
> want to go behind distros requesting fixes.
>
> > I agree with you in general, but again, this is a specific
> > platform quirk where I have a good idea of what is a
> > supported configuration.
>
> I am just nervous about future bios changes etc.
Ok, let's separate the two conversations happening here.
To me, the BIOS concerns are moot. I work closely with the BIOS
engineers for this platform; I have knowledge of future plans for
this BIOS and platform; and I know that they will not make any
changes that break the assumptions in my patch.
If they do, we will catch it during platform testing, file a bug,
and not let them release their BIOS until it's fixed. Does that
satisfy you? :)
So the algorithm for mapping an APIC ID to a physical/chassis ID
for this platform will not ever change.
Now on the other hand, the /interface/ that we present to the
user is the interesting conversation to have.
> > > Easiest route will be to add a new entry in /proc/cpuinfo
> >
> > Well, if you remain unconvinced that fixing up 'physical id' is
> > the proper thing to do, here are some alternate proposals:
> >
> > /proc/cpuinfo/chassis id
> > /sys/devices/system/cpu/$cpu/chassis id
> > /sys/devices/system/cpu/$cpu/topology/chassis id
> >
>
> I really like this alternate proposal. This is simple and straight
> forward to everyone.
I am leaning towards sysfs, and prefer:
/sys/devices/system/cpu/$cpu/chassis_id
How does that sound?
Thanks.
/ac
next prev parent reply other threads:[~2009-08-20 20:54 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-14 16:36 [PATCH] x86: add /proc/cpuinfo/physical id quirks Alex Chiang
2009-08-14 19:07 ` Suresh Siddha
2009-08-14 19:27 ` Alex Chiang
2009-08-14 19:56 ` Suresh Siddha
2009-08-19 21:02 ` Alex Chiang
2009-08-20 18:56 ` Suresh Siddha
2009-08-20 20:54 ` Alex Chiang [this message]
2009-08-20 21:03 ` Andi Kleen
2009-08-20 21:20 ` Alex Chiang
2009-08-20 21:26 ` Suresh Siddha
2009-08-20 21:42 ` H. Peter Anvin
2009-08-20 21:59 ` Alex Chiang
2009-08-20 22:04 ` H. Peter Anvin
2009-08-21 0:32 ` Andi Kleen
2009-08-21 1:51 ` H. Peter Anvin
2009-08-21 5:02 ` Alex Chiang
2009-08-20 21:22 ` Suresh Siddha
2009-08-21 0:38 ` Andi Kleen
2009-08-20 21:11 ` Suresh Siddha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090820205425.GF13061@ldl.fc.hp.com \
--to=achiang@hp.com \
--cc=andi@firstfloor.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.