[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <18539.8141.683072.967851@cargo.ozlabs.ibm.com>
Date: Wed, 2 Jul 2008 16:27:25 +1000
From: Paul Mackerras <paulus@...ba.org>
To: akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
linux-kernel@...r.kernel.org, greg@...ah.com
Subject: Is sysfs the right place to get cache and CPU topology info?
I'm being asked by library developers about what is the best way for
them to get information about the CPU cache structure and the CPU
topology from the kernel. When I said "x86 puts it in sysfs and we'll
do the same on powerpc" I got a response pointing me at this statement
in Documentation/sysfs-rules.txt (the first paragraph):
"The kernel-exported sysfs exports internal kernel implementation details
and depends on internal kernel structures and layout. It is agreed upon
by the kernel developers that the Linux kernel does not provide a stable
internal API. As sysfs is a direct export of kernel internal
structures, the sysfs interface cannot provide a stable interface either;
it may always change along with internal kernel changes."
They read that to mean that sysfs is not a suitable interface for them
to use to get information about the system. In particular they read
that to mean that if they do code their library to read sysfs, it will
change in the future in such a way as to break their code.
In other words, they see sysfs as being completely useless for them
because they can't depend on it as a stable interface. Which is
reasonable given the quoted paragraph, but on the other hand, I don't
believe we break userspace interfaces as blithely as that paragraph
suggests.
So which is it? Can they rely on the CPU cache and topology
information under /sys/devices/system/cpu/cpu*, and rely on having
that information there essentially forever? Or are they correct in
saying sysfs is useless and we need to find some other way to expose
the cache and topology information?
Thanks,
Paul.
--
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/
Powered by blists - more mailing lists