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-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ