From: Dave Hansen <haveblue@us.ibm.com>
To: Russ Anderson <rja@sgi.com>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Linux memory error handling
Date: Mon, 20 Jun 2005 14:07:35 -0700 [thread overview]
Message-ID: <1119301655.27442.14.camel@localhost> (raw)
In-Reply-To: <200506202042.j5KKgXKl4801437@clink.americas.sgi.com>
On Mon, 2005-06-20 at 15:42 -0500, Russ Anderson wrote:
> Is there a standard for how to name hardware entries in
> /sys/devices/system (or sysfs in general)?
For system devices, no, I don't think so.
> Seems like his same general issue would apply to other hardware
> components, cpus, nodes, etc.
I don't think it's true for anything other than memory. Linux doesn't
manage CPUs or nodes any differently than it manages its internal
representations of them.
But, for memory at a level any less granular than pages, Linux and the
hardware seldom have the same view.
> > One other minor thing. You might want to think about referring to the
> > pieces of memory as things other than DIMMs. On ppc64, for instance,
> > the hypervisor hands off memory in sections called LMBs (logical memory
> > blocks), and they're not directly related to any hardware DIMM. The
> > same things will show up in other virtualized environments.
>
> If we're talking about specific hardware entries, it seems like they
> should be called what they are. If we're talking about abstractions,
> a more abstract name seems in order. One of my concerns is mapping
> failures back to hardware components, hence my bias for component names.
Even with generic names mapping back to components should be easy
Somethinng like memory/type could even contain the hardware type of each
ram entry.
> Would having /sys/.../memory/LMB on ppc64 to correspond to
> /sys/.../memory/DIMM be a problem?
No, it wouldn't really be too much of a problem. But, it's not a very
accurate description. There is certainly hardware that has RAM which
does not have a single DIMM. :)
> RAM would be an alternative,
> but that could be confused with /sys/block/ram. :-)
RAM would probably be fine. There should be very few properties
that /sys/devices/system devices share with /sys/block, so it shouldn't
be too bad.
> In general, I'm more concerned with getting the necessary functionality
> in than what the specific entries are called, so I'll go along with
> the consensus.
I don't think there's much of a consensus. I just want to make sure we
do something that works on all platforms consistently. For instance,
I'd hate to have every userspace utilities that are trying to examine
memory look like this:
if [ `uname -a` == ppc64 ]; then
UNIT=LMB
elif [ `uname -a` == ia64 ]; then
UNIT=DIMM
etc...
FILE=/sys/devices/system/memory/$UNIT$NUMBER
-- Dave
next prev parent reply other threads:[~2005-06-20 21:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-15 14:30 [RCF] Linux memory error handling Russ Anderson
2005-06-15 15:08 ` Andi Kleen
2005-06-15 16:36 ` Russ Anderson
2005-06-15 15:26 ` Maciej W. Rozycki
2005-06-15 19:46 ` Russell King
2005-06-15 20:28 ` [RFC] " Russ Anderson
2005-06-15 20:45 ` Dave Hansen
2005-06-15 21:27 ` Russ Anderson
2005-06-15 21:33 ` Dave Hansen
2005-06-20 20:42 ` Russ Anderson
2005-06-20 21:07 ` Dave Hansen [this message]
2005-06-15 22:09 ` Russ Anderson
2005-06-16 19:42 ` Maciej W. Rozycki
2005-06-16 1:03 ` [RCF] " Ross Biro
2005-06-15 20:42 ` Joel Schopp
2005-06-16 2:54 ` Wang, Zhenyu
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=1119301655.27442.14.camel@localhost \
--to=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rja@sgi.com \
--cc=rmk+lkml@arm.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox