From: Andrew Morton <akpm@linux-foundation.org>
To: Paul Mackerras <paulus@samba.org>
Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
greg@kroah.com
Subject: Re: Is sysfs the right place to get cache and CPU topology info?
Date: Wed, 2 Jul 2008 00:37:55 -0700 [thread overview]
Message-ID: <20080702003755.4daff613.akpm@linux-foundation.org> (raw)
In-Reply-To: <18539.8141.683072.967851@cargo.ozlabs.ibm.com>
On Wed, 2 Jul 2008 16:27:25 +1000 Paul Mackerras <paulus@samba.org> wrote:
> 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."
Those are dopey weasel words and they should be removed.
If we put stuff in sysfs then people WILL use it and we WILL need to
support it for ever. Pointing at some document and saying "call my
lawyer" just won't cut it.
sysfs is part of the kernel ABI. We should design our interfaces there
as carefully as we design any others.
> 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.
Well it's up to them - they own the files. If they later change them
and break their own interfaces (and presumably their own applications),
well, perhaps they have chosen an inappropriate career?
> 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?
Use sysfs. Choose a representation which is maitainable in a
backward-compatible fashion for all time. Maintain it.
next prev parent reply other threads:[~2008-07-02 7:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-02 6:27 Is sysfs the right place to get cache and CPU topology info? Paul Mackerras
2008-07-02 7:37 ` Andrew Morton [this message]
2008-07-02 9:45 ` Paul Mackerras
2008-07-02 10:01 ` Andrew Morton
2008-07-02 11:46 ` Paul Mackerras
2008-07-02 16:47 ` Andrew Morton
2008-07-02 11:12 ` Andi Kleen
2008-07-02 14:35 ` Nathan Lynch
2008-07-02 15:14 ` Andi Kleen
2008-07-02 18:51 ` Greg KH
2008-07-02 21:41 ` Removing sysdevs? (was: Re: Is sysfs the right place to get cache and CPU topology info?) Rafael J. Wysocki
2008-07-02 21:48 ` Greg KH
2008-07-02 21:57 ` Removing sysdevs? Andi Kleen
2008-07-02 22:15 ` Greg KH
2008-07-03 9:53 ` Andi Kleen
2008-07-04 1:09 ` Greg KH
2008-07-02 22:17 ` Benjamin Herrenschmidt
2008-07-02 22:08 ` Removing sysdevs? (was: Re: Is sysfs the right place to get cache and CPU topology info?) Rafael J. Wysocki
2008-07-02 22:16 ` Greg KH
2008-07-02 23:06 ` Rafael J. Wysocki
2008-07-02 17:08 ` [PATCH] sysfs-rules.txt: reword API stability statement Nathan Lynch
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=20080702003755.4daff613.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox