lparcfg seq_file updates (pass2)

PATCH In review will schmidt 2 participants 2 messages Jul 1, 2004

lore

Share & tools

lore

will schmidt

author

2004-07-01 21:17 UTC #0 lore raw

PATCH 1/1 lparcfg seq_file updates (pass2)

Hi All,
This is another pass at the lparcfg changes. I believe i've got the
whitespace problem fixed up.

- Per Pauls request I've removed the vpurr references, and left just a stub function get_purr().
- Answering Dave's question on the lparcfg_count_active_processors() function.. This is for the cases where we have some number of virtual processors that are different than the number of physical processors in the system. This doesnt happen on most systems, but does occur in some of the partitioned configurations. I've added a similar comment above the function.
- this should apply clean to latest linus tree. (test-applied against 2.6.7-rc3).

This patch includes updates and cleanup for the PPC64 proc/lparcfg interface.
- use seq_file's seq_printf for output
- remove redundant e2a function. (use viopath.c's instead)
- change to Kconfig to allow building as a module.
- export required symbols from LparData.c

Please apply. (or provide comments..)
Thanks,
-Will

Signed-off-by Will Schmidt <[email protected]>

arch/ppc64/Kconfig +1 -1

diff -urN linux-2.6.7.orig/arch/ppc64/Kconfig linux-2.6.7/arch/ppc64/Kconfig
@@ -226,7 +226,7 @@
 	depends on PPC_RTAS
 
 config LPARCFG
-	bool "LPAR Configuration Data"
+	tristate "LPAR Configuration Data"
 	help
 	Provide system capacity information via human readable
 	<key word>=<value> pairs through a /proc/ppc64/lparcfg interface.

arch/ppc64/kernel/LparData.c +3 -0

diff -urN linux-2.6.7.orig/arch/ppc64/kernel/LparData.c linux-2.6.7/arch/ppc64/kernel/LparData.c
@@ -10,6 +10,7 @@
 #include <asm/page.h>
 #include <stddef.h>
 #include <linux/threads.h>
+#include <linux/module.h>
 #include <asm/processor.h>
 #include <asm/ptrace.h>
 #include <asm/naca.h>

@@ -123,12 +124,14 @@
 		(u64)InstructionAccessSLB_Iseries /* 0x480 I-SLB */
 	}
 };
+EXPORT_SYMBOL(itLpNaca);
 
 /* May be filled in by the hypervisor so cannot end up in the BSS */
 struct ItIplParmsReal xItIplParmsReal __attribute__((__section__(".data")));
 
 /* May be filled in by the hypervisor so cannot end up in the BSS */
 struct ItExtVpdPanel xItExtVpdPanel __attribute__((__section__(".data")));
+EXPORT_SYMBOL(xItExtVpdPanel);
 
 #define maxPhysicalProcessors 32

arch/ppc64/kernel/lparcfg.c +237 ~~-263~~

649 lines not on this page · raw message

arch/ppc64/kernel/viopath.c +2 -1

diff -urN linux-2.6.7.orig/arch/ppc64/kernel/viopath.c linux-2.6.7/arch/ppc64/kernel/viopath.c
@@ -108,7 +108,7 @@
 #define VIOPATH_KERN_WARN	KERN_WARNING "viopath: "
 #define VIOPATH_KERN_INFO	KERN_INFO "viopath: "
 
-static unsigned char e2a(unsigned char x)
+unsigned char e2a(unsigned char x)
 {
 	switch (x) {
 	case 0xF0:

@@ -186,6 +186,7 @@
 	}
 	return ' ';
 }
+EXPORT_SYMBOL(e2a);
 
 static int proc_viopath_show(struct seq_file *m, void *v)
 {

Dave Hansen

2004-07-01 21:36 UTC #1 lore raw

Quoted 6 lines · will schmidt

- Answering Dave's question on the lparcfg_count_active_processors() function.. This is for the cases where we have some number of virtual processors that are different than the number of physical processors in the system. This doesnt happen on most systems, but does occur in some of the partitioned configurations. I've added a similar comment above the function.

But, shouldn't the number of virtual processors be what shows up in sysfs and /proc/cpuinfo? I can understand exporting the number total in the machine, because that's not normally visible, but I think the number visible to Linux is redundant.

-- Dave