[PATCH 0/3] Transition /proc/cpuinfo -> sysfs

[PATCH 0/3] Transition /proc/cpuinfo -> sysfs

[Deepak Saxena]

Following this email will be a set of patches that provide a first pass
at exporting information currently in /proc/cpuinfo to sysfs for i386 and 
ARM. There are applications that are dependent on /proc/cpuinfo atm, so we 
can't just kill it, but we should agree on a kill date and require all
arches & apps to transition by that point. I've added code to
proc_misc.c to remind the user that the cpuinfo interface is going
away (currently using arbitrary date ~1 year from now). I've also
added a pointer to struct cpu that can be used by arch code to 
store any information that might be needed during attribute printing.

Couple of questions:

- Do we want to standardize on a set of attributes that all CPUs
  must provide to sysfs? bogomips, L1 cache size/type/sets/assoc (when
  available), L2 cache (L3..L4), etc? This would make the output be the 
  same across architectures for those features and would simply require
  adding some fields to struct cpu to carry this data and some generic
  ATTR entries to drivers/base/cpu.c.  I am all for standardized
  interfaces so I'll do a first pass at this if desired.

- On an HT setup, do we want link(s) pointing to sibling(s)?

- Currently the bug and feature fields on x86 have "yes" and "no".
  Do we want the same in sysfs or 1|0?

- Instead of dumping the "flags" field, should we just dump cpu
  registers as hex strings and let the user decode (as the comment
  for the x86_cap_flags implies.

I'll try to do MIPS, SH, and PPC when I get a chance (all I have access 
to), but have other things to do for a while, so want comments on above 
questions first. 

Tnx,
~Deepak

-- 
Deepak Saxena - dsaxena at plexity dot net - http://www.plexity.net/

"Unlike me, many of you have accepted the situation of your imprisonment and
 will die here like rotten cabbages." - Number 6

[PATCH 1/3] [Generic] Transition /proc/cpuinfo -> sysfs

[Deepak Saxena]

- Add printk to cpuinfo_open reminding user to transition to sysfs
- Add arch_cpuinfo field to struct cpu

diff -Nru a/fs/proc/proc_misc.c b/fs/proc/proc_misc.c
--- a/fs/proc/proc_misc.c	Wed Aug 11 14:46:15 2004
+++ b/fs/proc/proc_misc.c	Wed Aug 11 14:46:15 2004
@@ -258,11 +258,18 @@
 	return proc_calc_metrics(page, start, off, count, eof, len);
 }
 
+#define	CPUINFO_REMOVAL_DATE "September 1st, 2005"
 extern struct seq_operations cpuinfo_op;
 static int cpuinfo_open(struct inode *inode, struct file *file)
 {
+	printk(KERN_WARNING "Using depecrated /proc/cpuinfo interface\n");
+	printk(KERN_WARNING "This interface will be deleted on %s\n", 
+			CPUINFO_REMOVAL_DATE);
+	printk(KERN_WARNING "Please use syfs interface instead\n");
+
 	return seq_open(file, &cpuinfo_op);
 }
+
 static struct file_operations proc_cpuinfo_operations = {
 	.open		= cpuinfo_open,
 	.read		= seq_read,
diff -Nru a/include/linux/cpu.h b/include/linux/cpu.h
--- a/include/linux/cpu.h	Wed Aug 11 14:46:15 2004
+++ b/include/linux/cpu.h	Wed Aug 11 14:46:15 2004
@@ -28,6 +28,7 @@
 struct cpu {
 	int node_id;		/* The node which contains the CPU */
 	int no_control;		/* Should the sysfs control file be created? */
+	void *arch_cpuinfo;	/* Per-cpu arch data */
 	struct sys_device sysdev;
 };
 

-- 
Deepak Saxena - dsaxena at plexity dot net - http://www.plexity.net/

"Unlike me, many of you have accepted the situation of your imprisonment and
 will die here like rotten cabbages." - Number 6

[PATCH 2/3] [i386] Transition /proc/cpuinfo -> sysfs

[Deepak Saxena]

Ughh..found a bug already. Should check register_cpu() return value b4 
calling create_sysfs_cpu_entries().

diff -Nru a/arch/i386/kernel/cpu/Makefile b/arch/i386/kernel/cpu/Makefile
--- a/arch/i386/kernel/cpu/Makefile	Wed Aug 11 14:46:15 2004
+++ b/arch/i386/kernel/cpu/Makefile	Wed Aug 11 14:46:15 2004
@@ -2,7 +2,7 @@
 # Makefile for x86-compatible CPU details and quirks
 #
 
-obj-y	:=	common.o proc.o
+obj-y	:=	common.o proc.o sysfs.o
 
 obj-y	+=	amd.o
 obj-y	+=	cyrix.o
diff -Nru a/arch/i386/kernel/cpu/proc.c b/arch/i386/kernel/cpu/proc.c
--- a/arch/i386/kernel/cpu/proc.c	Wed Aug 11 14:46:15 2004
+++ b/arch/i386/kernel/cpu/proc.c	Wed Aug 11 14:46:15 2004
@@ -9,55 +9,10 @@
  */
 static int show_cpuinfo(struct seq_file *m, void *v)
 {
-	/* 
-	 * These flag bits must match the definitions in <asm/cpufeature.h>.
-	 * NULL means this bit is undefined or reserved; either way it doesn't
-	 * have meaning as far as Linux is concerned.  Note that it's important
-	 * to realize there is a difference between this table and CPUID -- if
-	 * applications want to get the raw CPUID data, they should access
-	 * /dev/cpu/<cpu_nr>/cpuid instead.
-	 */
-	static char *x86_cap_flags[] = {
-		/* Intel-defined */
-	        "fpu", "vme", "de", "pse", "tsc", "msr", "pae", "mce",
-	        "cx8", "apic", NULL, "sep", "mtrr", "pge", "mca", "cmov",
-	        "pat", "pse36", "pn", "clflush", NULL, "dts", "acpi", "mmx",
-	        "fxsr", "sse", "sse2", "ss", "ht", "tm", "ia64", "pbe",
-
-		/* AMD-defined */
-		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
-		NULL, NULL, NULL, "syscall", NULL, NULL, NULL, NULL,
-		NULL, NULL, NULL, "mp", "nx", NULL, "mmxext", NULL,
-		NULL, NULL, NULL, NULL, NULL, "lm", "3dnowext", "3dnow",
-
-		/* Transmeta-defined */
-		"recovery", "longrun", NULL, "lrti", NULL, NULL, NULL, NULL,
-		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
-		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
-		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
-
-		/* Other (Linux-defined) */
-		"cxmmx", "k6_mtrr", "cyrix_arr", "centaur_mcr",
-		NULL, NULL, NULL, NULL,
-		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
-		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
-		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
-
-		/* Intel-defined (#2) */
-		"pni", NULL, NULL, "monitor", "ds_cpl", NULL, NULL, "tm2",
-		"est", NULL, "cid", NULL, NULL, NULL, NULL, NULL,
-		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
-		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
-
-		/* VIA/Cyrix/Centaur-defined */
-		NULL, NULL, "rng", "rng_en", NULL, NULL, "ace", "ace_en",
-		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
-		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
-		NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
-	};
 	struct cpuinfo_x86 *c = v;
 	int i, n = c - cpu_data;
 	int fpu_exception;
+	extern char *x86_cap_flags[];
 
 #ifdef CONFIG_SMP
 	if (!cpu_online(n))
diff -Nru a/arch/i386/kernel/cpu/sysfs.c b/arch/i386/kernel/cpu/sysfs.c
--- /dev/null	Wed Dec 31 16:00:00 1969
+++ b/arch/i386/kernel/cpu/sysfs.c	Wed Aug 11 14:46:15 2004
@@ -0,0 +1,234 @@
+/*
+ * arch/i386/cpu/sysfs.c
+ *
+ * Export x86 CPU attributes to sysfs tree
+ *
+ * Author: Deepak Saxena <dsaxena@plexity.net>
+ *
+ * Copyright 2004 (c) MontaVista Software, Inc. 
+ * 
+ * This file is licensed under  the terms of the GNU General Public 
+ * License version 2. This program is licensed "as is" without any 
+ * warranty of any kind, whether express or implied.
+ *
+ *************************************************************************
+ *
+ * TODO/Questions: 
+ *   - Have link b/w HT siblings?
+ *   - Come up with generic, cross-arch set of attributes?
+ *   - Export features as 1|0 instead of "yes"|"no"?
+ *   - Export cpuid instead of "flags" attribute
+ *
+ */
+#include <linux/config.h>
+#include <linux/kernel.h>
+#include <linux/stddef.h>
+#include <linux/cpu.h>
+#include <linux/string.h>
+#include <linux/sysfs.h>
+
+#include <asm/cpu.h>
+#include <asm/processor.h>
+
+/* 
+ * These flag bits must match the definitions in <asm/cpufeature.h>.
+ * NULL means this bit is undefined or reserved; either way it doesn't
+ * have meaning as far as Linux is concerned.  Note that it's important
+ * to realize there is a difference between this table and CPUID -- if
+ * applications want to get the raw CPUID data, they should access
+ * /dev/cpu/<cpu_nr>/cpuid instead.
+ *
+ * TODO: Make this static when /proc/cpuinfo dies
+ */
+char *x86_cap_flags[] = {
+	/* Intel-defined */
+        "fpu", "vme", "de", "pse", "tsc", "msr", "pae", "mce",
+        "cx8", "apic", NULL, "sep", "mtrr", "pge", "mca", "cmov",
+        "pat", "pse36", "pn", "clflush", NULL, "dts", "acpi", "mmx",
+        "fxsr", "sse", "sse2", "ss", "ht", "tm", "ia64", "pbe",
+
+	/* AMD-defined */
+	NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+	NULL, NULL, NULL, "syscall", NULL, NULL, NULL, NULL,
+	NULL, NULL, NULL, "mp", "nx", NULL, "mmxext", NULL,
+	NULL, NULL, NULL, NULL, NULL, "lm", "3dnowext", "3dnow",
+
+	/* Transmeta-defined */
+	"recovery", "longrun", NULL, "lrti", NULL, NULL, NULL, NULL,
+	NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+	NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+	NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+
+	/* Other (Linux-defined) */
+	"cxmmx", "k6_mtrr", "cyrix_arr", "centaur_mcr",
+	NULL, NULL, NULL, NULL,
+	NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+	NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+	NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+
+	/* Intel-defined (#2) */
+	"pni", NULL, NULL, "monitor", "ds_cpl", NULL, NULL, "tm2",
+	"est", NULL, "cid", NULL, NULL, NULL, NULL, NULL,
+	NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+	NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+
+	/* VIA/Cyrix/Centaur-defined */
+	NULL, NULL, "rng", "rng_en", NULL, NULL, "ace", "ace_en",
+	NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+	NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+	NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+};
+
+/*
+ * We may be building w/o sysfs support, but we still need 
+ * to include this file so the above table can be used by the
+ * /procf/cpuinfo code. This goes away when we kill /proc/cpuinfo
+ */
+#ifdef CONFIG_SYSFS
+
+/*
+ * Helper function for simple attribute definitions.
+ */
+#define	X86_CPU_ATTR(_attr, _data, _format)				\
+static ssize_t show_##_attr(struct sys_device *dev, char *buf)		\
+{									\
+	struct cpu *cpu = 						\
+		(struct cpu*)container_of(dev, struct cpu, sysdev);	\
+	struct cpuinfo_x86 *c = 					\
+			(struct cpuinfo_x86*)cpu->arch_cpuinfo; 	\
+									\
+	return sprintf(buf, _format, _data);				\
+}									\
+SYSDEV_ATTR(_attr, 0644, show_##_attr, NULL);
+
+X86_CPU_ATTR(family, c->x86, "%d\n");
+X86_CPU_ATTR(model, c->x86_model, "%d\n");
+X86_CPU_ATTR(cpuid_level, c->cpuid_level, "%d\n");
+X86_CPU_ATTR(fdiv_bug, (c->fdiv_bug ? "yes" : "no"), "%s\n");
+X86_CPU_ATTR(coma_bug, (c->coma_bug ? "yes" : "no"), "%s\n");
+X86_CPU_ATTR(f00f_bug, (c->f00f_bug ? "yes" : "no"), "%s\n");
+X86_CPU_ATTR(fpu, (c->hard_math ? "yes" : "no"), "%s\n");
+X86_CPU_ATTR(wp, (c->wp_works_ok ? "yes" : "no"), "%s\n");
+X86_CPU_ATTR(hlt_bug, (c->hlt_works_ok ? "no" : "yes"), "%s\n");
+
+X86_CPU_ATTR(cache_size, (c->x86_cache_size), "%d KB\n");
+
+X86_CPU_ATTR(fpu_exception, 
+		c->hard_math && (ignore_fpu_irq || cpu_has_fpu), 
+		"%d\n");
+
+X86_CPU_ATTR(vendor_id, 
+		(c->x86_vendor_id[0] ? c->x86_vendor_id : "unknown"),
+		"%s\n");
+
+X86_CPU_ATTR(model_id, 
+		(c->x86_model_id[0] ? c->x86_model_id : "unknown"),
+		"%s\n");
+
+static ssize_t show_stepping(struct sys_device *dev, char *buf)
+{
+	struct cpu *cpu = (struct cpu *)container_of(dev, struct cpu, sysdev);
+	struct cpuinfo_x86  *c = (struct cpuinfo_x86 *)cpu->arch_cpuinfo;
+
+	if (c->x86_mask || c->cpuid_level >= 0)
+		return sprintf(buf, "%d\n", c->x86_mask);
+	else
+		return sprintf(buf, "unknown\n");
+}
+SYSDEV_ATTR(stepping, 0644, show_stepping, NULL);
+
+static ssize_t show_mhz(struct sys_device *dev, char *buf)
+{
+	struct cpu *cpu = (struct cpu *)container_of(dev, struct cpu, sysdev);
+	struct cpuinfo_x86  *c = (struct cpuinfo_x86 *)cpu->arch_cpuinfo;
+
+	if ( cpu_has(c, X86_FEATURE_TSC) ) {
+		return sprintf(buf, "%lu.%03lu\n", 
+			cpu_khz / 1000, (cpu_khz % 1000));
+	} else {
+		return sprintf(buf, "unknown\n");
+	}
+}
+SYSDEV_ATTR(mhz, 0644, show_mhz, NULL);
+
+static ssize_t show_bogomips(struct sys_device *dev, char *buf)
+{
+	struct cpu *cpu = (struct cpu *)container_of(dev, struct cpu, sysdev);
+	struct cpuinfo_x86 *c = (struct cpuinfo_x86 *)cpu->arch_cpuinfo;
+
+	return sprintf(buf, "%lu.%02lu\n",
+			c->loops_per_jiffy/(500000/HZ),
+			(c->loops_per_jiffy/(5000/HZ)) % 100);
+}
+SYSDEV_ATTR(bogomips, 0644, show_bogomips, NULL);
+
+static ssize_t show_flags(struct sys_device *dev, char *buf)
+{
+	struct cpu *cpu = (struct cpu *)container_of(dev, struct cpu, sysdev);
+	struct cpuinfo_x86 *c = (struct cpuinfo_x86 *)cpu->arch_cpuinfo;
+	int ret = 0;
+	int i;
+
+	for (i = 0; i < 32*NCAPINTS; i++)
+		if (test_bit(i, c->x86_capability) && x86_cap_flags[i] != NULL)
+			ret += sprintf(buf + ret, "%s ", x86_cap_flags[i]);
+
+	ret += sprintf(buf, "\n");
+
+	return ret;
+}
+SYSDEV_ATTR(flags, 0644, show_flags, NULL);
+
+#ifdef CONFIG_X86_HT
+ssize_t show_physical_id(struct sys_device *dev, char *buf)
+{
+	struct cpu *cpu = (struct cpu *)container_of(dev, struct cpu, sysdev);
+	struct cpuinfo_x86 *c = (struct cpuinfo_x86 *)cpu->arch_cpuinfo;
+	extern int phys_proc_id[NR_CPUS];
+	int n = c - cpu_data;
+
+	return sprintf(buf, "%d\n", phys_proc_id[n]);
+}
+SYSDEV_ATTR(physical_id, 0644, show_physical_id, NULL);
+
+X86_CPU_ATTR(siblings, smp_num_siblings, "%d\n");
+#endif	/* CONFIG_X86_HT */
+
+static struct attribute *x86_cpu_attrs[] = {
+	&attr_family.attr,
+	&attr_model.attr,
+	&attr_cpuid_level.attr,
+	&attr_fdiv_bug.attr,
+	&attr_coma_bug.attr,
+	&attr_f00f_bug.attr,
+	&attr_fpu.attr,
+	&attr_wp.attr,
+	&attr_hlt_bug.attr,
+	&attr_cache_size.attr,
+	&attr_mhz.attr,
+	&attr_vendor_id.attr,
+	&attr_model_id.attr,
+	&attr_stepping.attr,
+	&attr_bogomips.attr,
+	&attr_flags.attr,
+	&attr_fpu_exception.attr,
+};
+
+static struct attribute_group x86_cpu_group = {
+	.attrs	= x86_cpu_attrs
+};
+
+void create_sysfs_cpu_entries(struct cpu *cpu)
+{
+	struct sys_device *dev = &cpu->sysdev;
+
+	sysfs_create_group(&dev->kobj, &x86_cpu_group);
+
+#ifdef	CONFIG_X86_HT
+	if (cpu_has_ht) {
+		sysdev_create_file(dev, &attr_physical_id);
+		sysdev_create_file(dev, &attr_siblings);
+	}
+#endif
+}
+#endif	/* CONFIG_SYSFS */
diff -Nru a/include/asm-i386/cpu.h b/include/asm-i386/cpu.h
--- a/include/asm-i386/cpu.h	Wed Aug 11 14:46:15 2004
+++ b/include/asm-i386/cpu.h	Wed Aug 11 14:46:15 2004
@@ -12,9 +12,11 @@
 };
 extern struct i386_cpu cpu_devices[NR_CPUS];
 
+extern void create_sysfs_cpu_entries(struct cpu*);
 
 static inline int arch_register_cpu(int num){
 	struct node *parent = NULL;
+	int ret;
 	
 #ifdef CONFIG_NUMA
 	int node = cpu_to_node(num);
@@ -22,7 +24,13 @@
 		parent = &node_devices[node].node;
 #endif /* CONFIG_NUMA */
 
-	return register_cpu(&cpu_devices[num].cpu, num, parent);
+	cpu_devices[num].cpu.arch_cpuinfo = &cpu_data[num];
+
+	ret = register_cpu(&cpu_devices[num].cpu, num, parent);
+
+	create_sysfs_cpu_entries(&cpu_devices[num].cpu);
+
+	return ret;
 }
 
 #endif /* _ASM_I386_CPU_H_ */

-- 
Deepak Saxena - dsaxena at plexity dot net - http://www.plexity.net/

"Unlike me, many of you have accepted the situation of your imprisonment and
 will die here like rotten cabbages." - Number 6

[PATCH 3/3] [ARM] Transition /proc/cpuinfo -> sysfs

[Deepak Saxena]

Russell, 

Please comment. I've moved some bits to being detected at boot time
and stuffed into a structure b/c it makes the sysfs code cleaner.
We can just have a macro handling most cases now since the values
stored as int or char* in the cpuinfo structure.

~Deepak

diff -Nru a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
--- a/arch/arm/kernel/setup.c	Wed Aug 11 14:46:15 2004
+++ b/arch/arm/kernel/setup.c	Wed Aug 11 14:46:15 2004
@@ -27,6 +27,7 @@
 #include <asm/elf.h>
 #include <asm/hardware.h>
 #include <asm/io.h>
+#include <asm/cpuinfo.h>
 #include <asm/procinfo.h>
 #include <asm/setup.h>
 #include <asm/mach-types.h>
@@ -53,6 +54,13 @@
 __setup("fpe=", fpe_setup);
 #endif
 
+static struct arm_cpuinfo cpuinfo;
+static struct cpu cpu[1] = {
+	{
+		.arch_cpuinfo = &cpuinfo
+	}
+};
+
 extern unsigned int mem_fclk_21285;
 extern void paging_init(struct meminfo *, struct machine_desc *desc);
 extern void convert_to_tag_list(struct tag *tags);
@@ -219,6 +227,18 @@
 #define CACHE_M(y)	((y) & (1 << 2))
 #define CACHE_LINE(y)	((y) & 3)
 
+static const char *hwcap_str[] = {
+	"swp",
+	"half",
+	"thumb",
+	"26bit",
+	"fastmult",
+	"fpa",
+	"vfp",
+	"edsp",
+	NULL
+};
+
 static inline void dump_cache(const char *prefix, unsigned int cache)
 {
 	unsigned int mult = 2 + (CACHE_M(cache) ? 1 : 0);
@@ -264,10 +284,23 @@
 	return cpu_arch;
 }
 
+#define get_cache_info(_size, _assoc, _line_size, _sets, cache)		\
+do {									\
+	unsigned int mult = 2 + (CACHE_M(cache) ? 1 : 0);		\
+									\
+	cpuinfo._size = mult << (8 + CACHE_SIZE(cache));		\
+	cpuinfo._assoc = (mult << CACHE_ASSOC(cache)) >> 1;		\
+	cpuinfo._line_size =  8 << CACHE_LINE(cache);			\
+	cpuinfo._sets =  						\
+		1 << (6 + CACHE_SIZE(cache) - CACHE_ASSOC(cache) -	\
+			    CACHE_LINE(cache));				\
+} while(0);
+
 static void __init setup_processor(void)
 {
 	extern struct proc_info_list __proc_info_begin, __proc_info_end;
 	struct proc_info_list *list;
+	int cache_info;
 
 	/*
 	 * locate processor in the list of supported processor
@@ -314,6 +347,48 @@
 	elf_hwcap = list->elf_hwcap;
 
 	cpu_proc_init();
+
+	cpuinfo.model = cpu_name;
+	cpuinfo.revision = (int)processor_id & 15;
+	cpuinfo.elf_platform = elf_platform;
+	cpuinfo.vendor = processor_id >> 24;
+	cpuinfo.architecture = proc_arch[cpu_architecture()];
+
+	if ((processor_id & 0x0000f000) == 0x00000000) {
+		cpuinfo.part = processor_id >> 4;
+		cpuinfo.variant = 0xfffffff;
+	} else {
+		if ((processor_id & 0x0000f000) == 0x00007000) {
+			/* ARM7 */
+			cpuinfo.variant = (processor_id >> 16) & 127;
+		} else {
+			/* post-ARM7 */
+			cpuinfo.variant = (processor_id >> 20) & 15;
+		}
+		cpuinfo.part = (processor_id >> 4) & 0xfff;
+	}
+
+	cache_info = read_cpuid(CPUID_CACHETYPE);
+	if (cache_info != processor_id) {
+		cpuinfo.cache_type = cache_types[CACHE_TYPE(cache_info)];
+		cpuinfo.cache_clean = cache_clean[CACHE_TYPE(cache_info)],
+		cpuinfo.cache_lockdown = cache_lockdown[CACHE_TYPE(cache_info)];
+		cpuinfo.cache_format = 
+			CACHE_S(cache_info) ? "Harvard" : "Unified";
+
+		if (CACHE_S(cache_info)) {
+			get_cache_info(icache_size, icache_assoc, 
+					icache_line_size, icache_sets, 
+					CACHE_ISIZE(cache_info));
+			get_cache_info(dcache_size, dcache_assoc, 
+					dcache_line_size, dcache_sets, 
+					CACHE_DSIZE(cache_info));
+		} else {
+			get_cache_info(cache_size, cache_assoc, 
+					cache_line_size, cache_sets, 
+					CACHE_ISIZE(cache_info));
+		}
+	}
 }
 
 static struct machine_desc * __init setup_machine(unsigned int nr)
@@ -740,49 +815,189 @@
 #endif
 }
 
-static struct cpu cpu[1];
 
-static int __init topology_init(void)
+/*
+ * We currently can only have 1 CPU on ARM, so we theoretically
+ * don't need to touch the incoming dev and can just dereference
+ * the global cpuinfo; however, doing it right in the first place
+ * will make life easier down the road.
+ */
+#define ARM_CPU_ATTR(_field, _format)					\
+static ssize_t show_##_field(struct sys_device*dev, char *buf)		\
+{									\
+	struct cpu *cpu = 						\
+		(struct cpu*)container_of(dev, struct cpu, sysdev);	\
+	struct arm_cpuinfo *cpuinfo = 					\
+				(struct arm_cpuinfo*)cpu->arch_cpuinfo; \
+									\
+	return sprintf(buf, _format, cpuinfo->_field);			\
+}									\
+SYSDEV_ATTR(_field, 0644, show_##_field, NULL);
+
+
+ARM_CPU_ATTR(model, "%s\n");
+ARM_CPU_ATTR(part, "%07x\n");
+ARM_CPU_ATTR(variant, "%x\n");
+ARM_CPU_ATTR(revision, "%d\n");
+ARM_CPU_ATTR(elf_platform, "%s\n");
+ARM_CPU_ATTR(vendor, "%#02x\n");
+ARM_CPU_ATTR(architecture, "ARMv%s\n");
+
+ARM_CPU_ATTR(cache_type, "%s\n");
+ARM_CPU_ATTR(cache_clean, "%s\n");
+ARM_CPU_ATTR(cache_lockdown, "%s\n");
+ARM_CPU_ATTR(cache_format, "%s\n");
+
+/*
+ * Unified cache attributes
+ */
+ARM_CPU_ATTR(cache_size, "%d\n");
+ARM_CPU_ATTR(cache_assoc, "%d\n");
+ARM_CPU_ATTR(cache_line_size, "%d\n");
+ARM_CPU_ATTR(cache_sets, "%d\n");
+
+/*
+ * Harvard cache attributes
+ */
+ARM_CPU_ATTR(icache_size, "%d\n");
+ARM_CPU_ATTR(icache_assoc, "%d\n");
+ARM_CPU_ATTR(icache_line_size, "%d\n");
+ARM_CPU_ATTR(icache_sets, "%d\n");
+ARM_CPU_ATTR(dcache_size, "%d\n");
+ARM_CPU_ATTR(dcache_assoc, "%d\n");
+ARM_CPU_ATTR(dcache_line_size, "%d\n");
+ARM_CPU_ATTR(dcache_sets, "%d\n");
+
+static ssize_t show_bogomips(struct sys_device *dev, char *buf)
 {
-	return register_cpu(cpu, 0, NULL);
+	return sprintf(buf, "%lu.%02lu\n",
+		   loops_per_jiffy / (500000/HZ),
+		   (loops_per_jiffy / (5000/HZ)) % 100);
 }
+static SYSDEV_ATTR(bogomips, 0644, show_bogomips, NULL);
 
-subsys_initcall(topology_init);
+/*
+ * TODO: Should we have one file per feature with just a 1 or 0 to
+ * let userspace know specific feature exists?
+ */
+static ssize_t show_features(struct sys_device *dev, char *buf)
+{
+	ssize_t ret;
+	int i;
 
-static const char *hwcap_str[] = {
-	"swp",
-	"half",
-	"thumb",
-	"26bit",
-	"fastmult",
-	"fpa",
-	"vfp",
-	"edsp",
-	NULL
+	ret = 0;
+	for (i = 0; hwcap_str[i]; i++)
+		if (elf_hwcap & (1 << i))
+			ret += sprintf(buf + ret, "%s ", hwcap_str[i]);
+
+	ret += sprintf(buf + ret, "\n");
+
+	return ret;
+}
+static SYSDEV_ATTR(features, 0644, show_features, NULL);
+
+static ssize_t show_hardware(struct sys_device *dev, char *buf)
+{
+	return sprintf(buf, "%s\n", machine_name);
+}
+static SYSDEV_ATTR(hardware, 0644, show_hardware, NULL);
+
+static ssize_t show_hardware_rev(struct sys_device *dev, char *buf)
+{
+	return sprintf(buf, "%04x\n", system_rev);
+}
+static SYSDEV_ATTR(hardware_rev, 0644, show_hardware_rev, NULL);
+
+static ssize_t show_hardware_serial(struct sys_device *dev, char *buf)
+{
+	return sprintf(buf, "%08x%08x\n", system_serial_high, system_serial_low);
+}
+static SYSDEV_ATTR(hardware_serial, 0644, show_hardware_serial, NULL);
+
+static struct attribute *standard_attrs[] = {
+	&attr_bogomips.attr,
+	&attr_features.attr,
+	&attr_model.attr,
+	&attr_part.attr,
+	&attr_variant.attr,
+	&attr_elf_platform.attr,
+	&attr_vendor.attr,
+	&attr_revision.attr,
+	&attr_architecture.attr,
+	&attr_cache_type.attr,
+	&attr_cache_clean.attr,
+	&attr_cache_lockdown.attr,
+	&attr_cache_format.attr,
+	&attr_hardware.attr,
+	&attr_hardware_rev.attr,
+	&attr_hardware_serial.attr
+};
+
+static struct attribute_group standard_group = {
+	.attrs = standard_attrs
 };
 
-static void
-c_show_cache(struct seq_file *m, const char *type, unsigned int cache)
+static struct attribute *unified_cache_attrs[] = {
+	&attr_cache_size.attr,
+	&attr_cache_assoc.attr,
+	&attr_cache_line_size.attr,
+	&attr_cache_sets.attr
+};
+
+static struct attribute_group unified_cache_group = {
+	.attrs = unified_cache_attrs
+};
+
+static struct attribute *harvard_cache_attrs[] = {
+	&attr_icache_size.attr,
+	&attr_icache_assoc.attr,
+	&attr_icache_line_size.attr,
+	&attr_icache_sets.attr,
+	&attr_dcache_size.attr,
+	&attr_dcache_assoc.attr,
+	&attr_dcache_line_size.attr,
+	&attr_dcache_sets.attr
+};
+
+static struct attribute_group harvard_cache_group = {
+	.attrs = harvard_cache_attrs
+};
+
+/*
+ * Register cpu with sysfs and fill in CPU attributes
+ */
+static int __init topology_init(void)
 {
-	unsigned int mult = 2 + (CACHE_M(cache) ? 1 : 0);
+	int ret;
+	struct sys_device *dev = &cpu->sysdev;
+	int cache_info;
+
+	ret = register_cpu(cpu, 0, NULL);
+	if (ret) return ret;
+
+	sysfs_create_group(&dev->kobj, &standard_group);
+
+	cache_info = read_cpuid(CPUID_CACHETYPE);
+	if (cache_info != processor_id) {
+		if (CACHE_S(cache_info)) {
+			sysfs_create_group(&dev->kobj, &harvard_cache_group);
+		} else {
+			sysfs_create_group(&dev->kobj, &unified_cache_group);
+		}
+	}	
 
-	seq_printf(m, "%s size\t\t: %d\n"
-		      "%s assoc\t\t: %d\n"
-		      "%s line length\t: %d\n"
-		      "%s sets\t\t: %d\n",
-		type, mult << (8 + CACHE_SIZE(cache)),
-		type, (mult << CACHE_ASSOC(cache)) >> 1,
-		type, 8 << CACHE_LINE(cache),
-		type, 1 << (6 + CACHE_SIZE(cache) - CACHE_ASSOC(cache) -
-			    CACHE_LINE(cache)));
+	return 0;
 }
 
+subsys_initcall(topology_init);
+
 static int c_show(struct seq_file *m, void *v)
 {
 	int i;
+	int cache_info;
 
 	seq_printf(m, "Processor\t: %s rev %d (%s)\n",
-		   cpu_name, (int)processor_id & 15, elf_platform);
+			cpuinfo.model, cpuinfo.revision, cpuinfo.elf_platform);
 
 	seq_printf(m, "BogoMIPS\t: %lu.%02lu\n",
 		   loops_per_jiffy / (500000/HZ),
@@ -795,45 +1010,47 @@
 		if (elf_hwcap & (1 << i))
 			seq_printf(m, "%s ", hwcap_str[i]);
 
-	seq_printf(m, "\nCPU implementer\t: 0x%02x\n", processor_id >> 24);
-	seq_printf(m, "CPU architecture: %s\n", proc_arch[cpu_architecture()]);
+	seq_printf(m, "\nCPU implementer\t: 0x%02x\n", cpuinfo.vendor);
+	seq_printf(m, "CPU architecture: %s\n", cpuinfo.architecture);
 
-	if ((processor_id & 0x0000f000) == 0x00000000) {
-		/* pre-ARM7 */
-		seq_printf(m, "CPU part\t\t: %07x\n", processor_id >> 4);
-	} else {
-		if ((processor_id & 0x0000f000) == 0x00007000) {
-			/* ARM7 */
-			seq_printf(m, "CPU variant\t: 0x%02x\n",
-				   (processor_id >> 16) & 127);
-		} else {
-			/* post-ARM7 */
-			seq_printf(m, "CPU variant\t: 0x%x\n",
-				   (processor_id >> 20) & 15);
-		}
-		seq_printf(m, "CPU part\t: 0x%03x\n",
-			   (processor_id >> 4) & 0xfff);
+	seq_printf(m, "CPU part\t\t: %07x\n", cpuinfo.part);
+	if ((processor_id & 0x0000f000) != 0x00000000) {
+		seq_printf(m, "CPU variant\t: 0x%x\n", cpuinfo.variant);
 	}
 	seq_printf(m, "CPU revision\t: %d\n", processor_id & 15);
 
-	{
-		unsigned int cache_info = read_cpuid(CPUID_CACHETYPE);
-		if (cache_info != processor_id) {
-			seq_printf(m, "Cache type\t: %s\n"
-				      "Cache clean\t: %s\n"
-				      "Cache lockdown\t: %s\n"
-				      "Cache format\t: %s\n",
-				   cache_types[CACHE_TYPE(cache_info)],
-				   cache_clean[CACHE_TYPE(cache_info)],
-				   cache_lockdown[CACHE_TYPE(cache_info)],
-				   CACHE_S(cache_info) ? "Harvard" : "Unified");
-
-			if (CACHE_S(cache_info)) {
-				c_show_cache(m, "I", CACHE_ISIZE(cache_info));
-				c_show_cache(m, "D", CACHE_DSIZE(cache_info));
-			} else {
-				c_show_cache(m, "Cache", CACHE_ISIZE(cache_info));
-			}
+	cache_info = read_cpuid(CPUID_CACHETYPE);
+	if (cache_info != processor_id) {
+		seq_printf(m, "Cache type\t: %s\n"
+			      "Cache clean\t: %s\n"
+			      "Cache lockdown\t: %s\n"
+			      "Cache format\t: %s\n",
+			   cpuinfo.cache_type, cpuinfo.cache_clean,
+			   cpuinfo.cache_lockdown, cpuinfo.cache_format);
+
+		if (CACHE_S(cache_info)) {
+			seq_printf(m, "I size\t\t: %d\n", cpuinfo.icache_size);
+			seq_printf(m, "I assoc\t\t: %d\n", 
+					cpuinfo.icache_assoc);
+			seq_printf(m, "I line length\t: %d\n", 
+					cpuinfo.icache_line_size);
+			seq_printf(m, "I sets\t\t: %d\n", cpuinfo.icache_sets);
+
+			seq_printf(m, "D size\t\t: %d\n", cpuinfo.dcache_size);
+			seq_printf(m, "D assoc\t\t: %d\n", 
+					cpuinfo.dcache_assoc);
+			seq_printf(m, "D line length\t: %d\n", 
+					cpuinfo.dcache_line_size);
+			seq_printf(m, "D sets\t\t: %d\n", cpuinfo.dcache_sets);
+		} else {
+			seq_printf(m, "Cache size\t\t: %d\n", 
+					cpuinfo.icache_size);
+			seq_printf(m, "Cache assoc\t\t: %d\n", 
+					cpuinfo.icache_assoc);
+			seq_printf(m, "Cache line length\t: %d\n", 
+					cpuinfo.icache_line_size);
+			seq_printf(m, "Cache sets\t\t: %d", 
+					cpuinfo.icache_sets);
 		}
 	}
 
@@ -868,3 +1085,4 @@
 	.stop	= c_stop,
 	.show	= c_show
 };
+
diff -Nru a/include/asm-arm/cpuinfo.h b/include/asm-arm/cpuinfo.h
--- /dev/null	Wed Dec 31 16:00:00 1969
+++ b/include/asm-arm/cpuinfo.h	Wed Aug 11 14:46:15 2004
@@ -0,0 +1,51 @@
+/*
+ * include/asm-arm/cpuinfo.h
+ *
+ * per-cpu information used for sysfs
+ *
+ * Author: Deepak Saxena <dsaxena@plexity.net>
+ *
+ * Copyright 2004 (c) MontaVista Software, Inc. 
+ * 
+ * This file is licensed under  the terms of the GNU General Public 
+ * License version 2. This program is licensed "as is" without any 
+ * warranty of any kind, whether express or implied.
+ */
+
+
+#ifndef __ASM_CPUINFO_H__
+#define __ASM_CPUINFO_H__
+
+
+struct arm_cpuinfo {
+	const char *model;
+	unsigned long part;
+	unsigned long variant;
+	const char *elf_platform;
+	unsigned char vendor;
+	unsigned short revision;
+	const char *architecture;
+
+	const char *cache_type;
+	const char *cache_clean;
+	const char *cache_lockdown;
+	const char *cache_format;
+
+	unsigned int cache_size;
+	unsigned int cache_assoc;
+	unsigned int cache_line_size;
+	unsigned int cache_sets;	
+
+	unsigned int icache_size;
+	unsigned int icache_assoc;
+	unsigned int icache_line_size;
+	unsigned int icache_sets;	
+
+	unsigned int dcache_size;
+	unsigned int dcache_assoc;
+	unsigned int dcache_line_size;
+	unsigned int dcache_sets;	
+};
+
+#endif	/* __ASM_CPUINFO_H__ */
+

-- 
Deepak Saxena - dsaxena at plexity dot net - http://www.plexity.net/

"Unlike me, many of you have accepted the situation of your imprisonment and
 will die here like rotten cabbages." - Number 6

Re: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs

[Deepak Saxena]

In case this goes into -mm, following applies to all 3 patches:

Signed-off-by: Deepak Saxena <dsaxena@plexit.net>

-- 
Deepak Saxena - dsaxena at plexity dot net - http://www.plexity.net/

"Unlike me, many of you have accepted the situation of your imprisonment and
 will die here like rotten cabbages." - Number 6

Re: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs

[Dave Jones]

On Wed, Aug 11, 2004 at 03:41:17PM -0700, Deepak Saxena wrote:

 > - Do we want to standardize on a set of attributes that all CPUs
 >   must provide to sysfs? bogomips, L1 cache size/type/sets/assoc (when
 >   available), L2 cache (L3..L4), etc?

For x86 at least, this can be entirely decoded in userspace using
the /dev/cpu/x/cpuid interface. See x86info for example of this.

 > - Instead of dumping the "flags" field, should we just dump cpu
 >   registers as hex strings and let the user decode (as the comment
 >   for the x86_cap_flags implies.

ditto.

As these require arch specific parsers anyway, I don't think it makes
too much sense making a kernel abstraction trying to make them all
look 'the same', and if it can be done in userspace, why bother ?

The only other concern I have is the further expansion of sysfs with
no particular gain over what we currently have. The sysfs variant
*will* use more unreclaimable RAM than the proc version.

/proc/cpuinfo has done well enough for us for quite a number of years
now, what makes it so urgent to kill it now that sysfs is the
virtual-fs-de-jour ?

		Dave

Re: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs

[Deepak Saxena]

On Aug 12 2004, at 00:13, Dave Jones was caught saying:
> On Wed, Aug 11, 2004 at 03:41:17PM -0700, Deepak Saxena wrote:
> 
>  > - Do we want to standardize on a set of attributes that all CPUs
>  >   must provide to sysfs? bogomips, L1 cache size/type/sets/assoc (when
>  >   available), L2 cache (L3..L4), etc?
> 
> For x86 at least, this can be entirely decoded in userspace using
> the /dev/cpu/x/cpuid interface. See x86info for example of this.
> 
>  > - Instead of dumping the "flags" field, should we just dump cpu
>  >   registers as hex strings and let the user decode (as the comment
>  >   for the x86_cap_flags implies.
> 
> ditto.

OK, just saw that code now and my reponse is to remove that 
interface in the long-term and move cpuid into sysfs (and not 
export all the cache info separately). In theory we don't even 
need the xxx_bug fields as those can be determined from looking
at CPU binary data.

> As these require arch specific parsers anyway, I don't think it makes
> too much sense making a kernel abstraction trying to make them all
> look 'the same', and if it can be done in userspace, why bother ?

If it is all done in userspace, then just having the raw binary
data available via sysfs w/o kernel parsing is probably best. The
question I have is are there any cross-platform userland tools/apps
that just want to know things like cache-size w/o worrying about
CPU specifics? Even if they do, I suppose they can be fixed to read
that information from a binary blob and parse it dependent on 
the arch. ARM (other arch I really care about) could just output 
all the various ID registers into a binary blob and I am sure the
same can be done for the other arches.

> The only other concern I have is the further expansion of sysfs with
> no particular gain over what we currently have. The sysfs variant
> *will* use more unreclaimable RAM than the proc version.

Agreed, but that hasn't kept other data such as PCI and partition 
information from moving into sysfs.

> /proc/cpuinfo has done well enough for us for quite a number of years
> now, what makes it so urgent to kill it now that sysfs is the
> virtual-fs-de-jour ?

Consitency in userspace interface. My understanding is that goal is to 
make /proc slowly return to it's original purpose (process-information) 
and move other data out into sysfs.  

~Deepak


-- 
Deepak Saxena - dsaxena at plexity dot net - http://www.plexity.net/

"Unlike me, many of you have accepted the situation of your imprisonment and
 will die here like rotten cabbages." - Number 6

Re: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs

[Dave Jones]

On Wed, Aug 11, 2004 at 04:42:45PM -0700, Deepak Saxena wrote:

 > > For x86 at least, this can be entirely decoded in userspace using
 > > the /dev/cpu/x/cpuid interface. See x86info for example of this.
 > > 
 > >  > - Instead of dumping the "flags" field, should we just dump cpu
 > >  >   registers as hex strings and let the user decode (as the comment
 > >  >   for the x86_cap_flags implies.
 > > 
 > > ditto.
 > 
 > OK, just saw that code now and my reponse is to remove that 
 > interface in the long-term and move cpuid into sysfs (and not 
 > export all the cache info separately).

but why? it's totally pointless when the same info can be obtained
from userspace without the bloat.

 > In theory we don't even 
 > need the xxx_bug fields as those can be determined from looking
 > at CPU binary data.

not all of them you can't iirc.

 > > As these require arch specific parsers anyway, I don't think it makes
 > > too much sense making a kernel abstraction trying to make them all
 > > look 'the same', and if it can be done in userspace, why bother ?
 > 
 > If it is all done in userspace, then just having the raw binary
 > data available via sysfs w/o kernel parsing is probably best.

the raw binary is already available. in /dev/cpu/x/cpuid
I repeat, duplicating this in sysfs is utterly pointless other than
to bloat the kernels runtime memory usage.

 > > The only other concern I have is the further expansion of sysfs with
 > > no particular gain over what we currently have. The sysfs variant
 > > *will* use more unreclaimable RAM than the proc version.
 > 
 > Agreed, but that hasn't kept other data such as PCI and partition 
 > information from moving into sysfs.

So because one subsystem decides to do it, every other should follow
lemming-like ?
 
 > > /proc/cpuinfo has done well enough for us for quite a number of years
 > > now, what makes it so urgent to kill it now that sysfs is the
 > > virtual-fs-de-jour ?
 > 
 > Consitency in userspace interface.

sorry, but I think that argument is total crap.  Any userspace tool needing
this info will still need to support the /dev/cpu/ interfaces if they want to
also run on 2.2 / 2.4 kernels.  Likewise, anything using /proc/cpuinfo.
Ripping this out does nothing useful that I see other than cause headache
for userspace by having yet another interface to support.

 > My understanding is that goal is to 
 > make /proc slowly return to it's original purpose (process-information) 
 > and move other data out into sysfs.  

I don't think thats a realistic goal. It'll take years just to migrate the
in-kernel stuff, and there's god alone knows how much out-of-tree code doing
the same, plus the add-ons from various vendor kernels etc so I doubt it'll
ever be the process-only utopia you envision.

Changing userspace interfaces on a whim just causes pain for those
that use them, especially when there is nothing wrong with the existing
interfaces.

		Dave

Re: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs

[Deepak Saxena]

On Aug 12 2004, at 00:59, Dave Jones was caught saying:
> 
> but why? it's totally pointless when the same info can be obtained
> from userspace without the bloat.
> 
<snip>
> 
> the raw binary is already available. in /dev/cpu/x/cpuid
> I repeat, duplicating this in sysfs is utterly pointless other than
> to bloat the kernels runtime memory usage.

I won't argue that there is no increase in memory usage. Looking at 
.text + .data for (i386/kernel/cpuid.c + i386/kernel/cpu/proc.c), there 
is a 2x increase (~1K -> ~2K) in size. I haven't looked at the runtime
memory required for extra the sysfs objects atm; however, given that sysfs 
is going to be used in just about every system out there (even small 
embedded devices), that size is probably negligble compared to the memory 
requirements for all the other users of sysfs. If we can look at
what really needs to be exported as a separate object and what
can be determined by userspace via parsing of binary blob, that
size diference will probably shrink considerably. 

>  > > /proc/cpuinfo has done well enough for us for quite a number of years
>  > > now, what makes it so urgent to kill it now that sysfs is the
>  > > virtual-fs-de-jour ?
>  > 
>  > Consitency in userspace interface.
> 
> sorry, but I think that argument is total crap.  Any userspace tool needing
> this info will still need to support the /dev/cpu/ interfaces if they want to
> also run on 2.2 / 2.4 kernels.  Likewise, anything using /proc/cpuinfo.
> Ripping this out does nothing useful that I see other than cause headache
> for userspace by having yet another interface to support.

In my original email I specifically said that we cannot remove /proc/cpuinfo 
today b/c of application requirements, but this is something for down
the road. The arbitrary date I choose (+1 year) can just as easilly be
+2 years to provide more time for apps to change over. Right now
there are 2 interfaces for cpu information via /proc/cpuinfo and /dev/cpu.
By moving to sysfs we can have 1 interface. That in itself seems like a
clear win.

>  > My understanding is that goal is to 
>  > make /proc slowly return to it's original purpose (process-information) 
>  > and move other data out into sysfs.  
> 
> I don't think thats a realistic goal. It'll take years just to migrate the
> in-kernel stuff, and there's god alone knows how much out-of-tree code doing
> the same, plus the add-ons from various vendor kernels etc so I doubt it'll
> ever be the process-only utopia you envision.

Nothing wrong with taking time. I never said we need to get rid of
stuff overnight. We can keep old interfaces around (see /proc/pci
for example) as long as it takes for core apps and kernel stuff
to switch over.

~Deepak

-- 
Deepak Saxena - dsaxena at plexity dot net - http://www.plexity.net/

"Unlike me, many of you have accepted the situation of your imprisonment and
 will die here like rotten cabbages." - Number 6

Re: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs

[Lamont R. Peterson]

[-- Attachment #1: Type: text/plain, Size: 2692 bytes --]

On Wed, 2004-08-11 at 16:41, Deepak Saxena wrote:
> Following this email will be a set of patches that provide a first pass
> at exporting information currently in /proc/cpuinfo to sysfs for i386 and 
> ARM. There are applications that are dependent on /proc/cpuinfo atm, so we 
> can't just kill it, but we should agree on a kill date and require all
> arches & apps to transition by that point. I've added code to
> proc_misc.c to remind the user that the cpuinfo interface is going
> away (currently using arbitrary date ~1 year from now). I've also
> added a pointer to struct cpu that can be used by arch code to 
> store any information that might be needed during attribute printing.
> 
> Couple of questions:
> 
> - Do we want to standardize on a set of attributes that all CPUs
>   must provide to sysfs? bogomips, L1 cache size/type/sets/assoc (when
>   available), L2 cache (L3..L4), etc? This would make the output be the 
>   same across architectures for those features and would simply require
>   adding some fields to struct cpu to carry this data and some generic
>   ATTR entries to drivers/base/cpu.c.  I am all for standardized
>   interfaces so I'll do a first pass at this if desired.

I vote yes, but only to a point.  You are right; standardized interfaces
are a good thing.  For any architecture specific information, additional
fields should be available.  Perhaps either always following the
standardized sysfs entries or as an "extra-cpuinfo" (or
"[arch]-cpuinfo"?) sysfs node.

> - On an HT setup, do we want link(s) pointing to sibling(s)?

I like this idea, even if it is not necessary because siblings should be
listed sequentially together.  i.e. two physical CPUs with HT would be
cpu0, cpu1, cpu2 & cpu3.  Obviously, cpu0 & cpu1 go together and cpu2 &
cpu3 also go together.

> - Currently the bug and feature fields on x86 have "yes" and "no".
>   Do we want the same in sysfs or 1|0?

If the flags are not going to be decoded, then I say definitely 1|0.

> - Instead of dumping the "flags" field, should we just dump cpu
>   registers as hex strings and let the user decode (as the comment
>   for the x86_cap_flags implies.

I like this.  In fact, if it goes this way, then I will write a
"cpuinfo" program that will do all the decoding as a generic tool.

> I'll try to do MIPS, SH, and PPC when I get a chance (all I have access 
> to), but have other things to do for a while, so want comments on above 
> questions first. 

When you are ready, I can also get SPARC64 & AMD64 (Opteron 242).
-- 
Lamont R. Peterson <lamont@gurulabs.com>
Senior Instructor
Guru Labs, L.C. http://www.GuruLabs.com/

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs

[Dave Jones]

On Wed, Aug 11, 2004 at 11:03:29PM -0600, Lamont R. Peterson wrote:

 > > - On an HT setup, do we want link(s) pointing to sibling(s)?
 > 
 > I like this idea, even if it is not necessary because siblings should be
 > listed sequentially together.  i.e. two physical CPUs with HT would be
 > cpu0, cpu1, cpu2 & cpu3.  Obviously, cpu0 & cpu1 go together and cpu2 &
 > cpu3 also go together.

I'll bet *any* userspace code wanting to know this info would be simpler
to write if you do the cpuid calls in the app and parse internally than
walking sysfs to form an interpretation.

 > > - Instead of dumping the "flags" field, should we just dump cpu
 > >   registers as hex strings and let the user decode (as the comment
 > >   for the x86_cap_flags implies.
 > 
 > I like this.  In fact, if it goes this way, then I will write a
 > "cpuinfo" program that will do all the decoding as a generic tool.

http://www.codemonkey.org.uk/projects/x86info/

Ok, its x86/amd64 specific, but it does all this parsing and the like
where it should be -- userspace.

		Dave

Re: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs

[Dave Jones]

On Wed, Aug 11, 2004 at 07:45:54PM -0700, Deepak Saxena wrote:

 > If we can look at
 > what really needs to be exported as a separate object and what
 > can be determined by userspace via parsing of binary blob, that
 > size diference will probably shrink considerably. 

And if we decide not to do this, the size difference shrinks even
more considerably. People who don't give a rats ass about this stuff
aren't wasting memory for each sysfs node.

The only justification I've seen so far for this bloat is
"other subsystems have put their crap in sysfs, so I want to do the same".

 > >  > > /proc/cpuinfo has done well enough for us for quite a number of years
 > >  > > now, what makes it so urgent to kill it now that sysfs is the
 > >  > > virtual-fs-de-jour ?
 > >  > Consitency in userspace interface.
 > > 
 > > sorry, but I think that argument is total crap.  Any userspace tool needing
 > > this info will still need to support the /dev/cpu/ interfaces if they want to
 > > also run on 2.2 / 2.4 kernels.  Likewise, anything using /proc/cpuinfo.
 > > Ripping this out does nothing useful that I see other than cause headache
 > > for userspace by having yet another interface to support.
 > 
 > In my original email I specifically said that we cannot remove /proc/cpuinfo 
 > today b/c of application requirements, but this is something for down
 > the road.

Yes. And then when presented with the "but this is useless, because we already
have /dev/cpu" argument, you decided to deprecate that for no reason too,
in the name of 'consistency'.

This is madness.

This 'consistency' costs. As I already mentioned, an application that
runs on any kernel would now have to support an extra method of obtaining
the data it needs.  Then people wonder why userspace apps are bloating
up further and further each year. Then people wonder why installers
suddenly need an extra xMB of RAM to install the latest version of
a distro.

 > Nothing wrong with taking time. I never said we need to get rid of
 > stuff overnight. We can keep old interfaces around (see /proc/pci
 > for example) as long as it takes for core apps and kernel stuff
 > to switch over.

There was a 'joke' a while ago about some corporations handing out
bonuses to its engineers each time a patch was accepted that removed
a user of the big kernel lock.  These days I wonder if the same
analogy is holding true for systfs patches.

		Dave

Re: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs

[Andrew Morton]

Dave Jones <davej@redhat.com> wrote:
>
>  > My understanding is that goal is to 
>   > make /proc slowly return to it's original purpose (process-information) 
>   > and move other data out into sysfs.  
> 
>  I don't think thats a realistic goal.

It may be realistic if we try hard enough, but I don't think it's a
desirable one at this time.  I'd prefer that I, Deepak and everyone else be
spending cycles on higher-priority things than these patches.  Sorry.

Re: [PATCH 0/3] Transition /proc/cpuinfo -> sysfs

[Greg KH]

On Sat, Aug 14, 2004 at 11:11:53PM -0700, Andrew Morton wrote:
> Dave Jones <davej@redhat.com> wrote:
> >
> >  > My understanding is that goal is to 
> >   > make /proc slowly return to it's original purpose (process-information) 
> >   > and move other data out into sysfs.  
> > 
> >  I don't think thats a realistic goal.
> 
> It may be realistic if we try hard enough, but I don't think it's a
> desirable one at this time.  I'd prefer that I, Deepak and everyone else be
> spending cycles on higher-priority things than these patches.  Sorry.

But things like this are fun to do at times :)

Anyway, that being said, I'm going to keep Deepak's patches around in my
personal trees and see how well they work out as they are something that
I've personally been interested in doing for quite some time.  If, after
a while, things look better, I'll ask for a trial time in the -mm tree
for them.

thanks,

greg k-h