/proc/sys/kernel/pointer_size

OProfile needs to know the pointer size being used for the kernel, on platforms with 32-bit userspace and 64-bit kernel. This patch adds a simple ro sysctl that exports this information as suggested by davem

thanks,
john

diff -X dontdiff -Naur linux-linus/include/linux/sysctl.h linux/include/linux/sysctl.h
@@ -129,6 +129,7 @@
 	KERN_CADPID=54,		/* int: PID of the process to notify on CAD */
 	KERN_PIDMAX=55,		/* int: PID # limit */
   	KERN_CORE_PATTERN=56,	/* string: pattern for core-file names */
+	KERN_POINTER_SIZE=57,	/* size_t: sizeof(void *) */
 };
 
 

diff -X dontdiff -Naur linux-linus/kernel/sysctl.c linux/kernel/sysctl.c
@@ -56,6 +56,9 @@
 extern int pid_max;
 extern int sysctl_lower_zone_protection;
 
+/* Needed when user-space is 32-bit with 64-bit kernel */
+static int pointer_size = (int)sizeof(void *);
+ 
 /* this is needed for the proc_dointvec_minmax for [fs_]overflow UID and GID */
 static int maxolduid = 65535;
 static int minolduid;

@@ -180,6 +183,8 @@
 	 0644, NULL, &proc_dointvec},
 	{KERN_CAP_BSET, "cap-bound", &cap_bset, sizeof(kernel_cap_t),
 	 0600, NULL, &proc_dointvec_bset},
+	{KERN_POINTER_SIZE, "pointer_size", &pointer_size, sizeof(int),
+	 0444, NULL, &proc_dointvec},
 #ifdef CONFIG_BLK_DEV_INITRD
 	{KERN_REALROOTDEV, "real-root-dev", &real_root_dev, sizeof(int),
 	 0644, NULL, &proc_dointvec},

No.

This is the kind of stupid bloat I do not want. The kernel pointer size doesn't change suddenly on the machine, there's no point at all in doing something like this and exporting it through proc, when the information is perfectly available in other ways or could even be a user program config file option.

There is _no_ excuse for a program asking for what the kernel pointer size is. Adding a random /proc file just because it's easy is not a good idea. Bloat is bloat, and 99% of all bloat comes one little feature at a time.

Quite frankly, just compile oprofile for the architecture and be done with it. Or add a command line option. Don't add stupid bloat to the kernel because somebody is silly enough to care about a 32-bit oprofile working with a 64-bit kernel.

Linus

What other ways ? Dave M reasonably argued it wasn't part of the architecture's ABI, so did not have a place in the headers.

Eww.

It's not silly, it's a necessity on architectures like pa-risc, sparc64, ppc64, etc. where pointers are 32 bit in userspace. OProfile simply cannot work at all on such systems without being able to figure out the units of the oprofile kernel buffer.

We could force the oprofile kernel buffer to always be u64s but that just eats unnecessary space and time on x86.

So, what solution do you suggest instead ?

regards
john

"CUT IT OUT FACEHEAD"
	- jeffk

You should certainly see it in "uname -a" output, for example.

And it's less disgusting than adding a kernel hack for it?

Trust me, kernel stuff is for stuff that _cannot_ be gotten in user space, not for random hacks.

So?

The same is true of kernel modules - 32-bit kernel modules do not work at all when the kernel is 64-bit.

Compile oprofile for the proper architecture if you do it yourself, and complain to the vendor if the vendor is stupid enough to supply a 32-bit oprofile with a 64-bit kernel.

There is _no_ excuse to bloat the kernel for user mistakes.

Linus

Hrmph. Actually we can take it from the ELF headers of the vmlinux file that gets passed in I suppose. Along with a uname hack for when there's no vmlinux available...

Modules aren't in userspace.

I don't see what's stupid about a 32-bit binary on a system where all of user-space is 32-bit. But it doesn't matter.

regards
john

"CUT IT OUT FACEHEAD"
	- jeffk

From: Linus Torvalds <[email protected]>
Date: Wed, 8 Jan 2003 13:03:14 -0800 (PST)

You should certainly see it in "uname -a" output, for example.

Doesn't tell you the kernel pointer size. We fake the uname output when a process runs as PERS_LINUX_32BIT which is what we use to trick 'configure' and other build programs in order to build 32-bit apps properly.

Compile oprofile for the proper architecture if you do it yourself, and complain to the vendor if the vendor is stupid enough to supply a 32-bit oprofile with a 64-bit kernel.

There is _no_ excuse to bloat the kernel for user mistakes.

There simply is no fully usable 64-bit userland on some of these platforms.

[email protected] (Linus Torvalds) wrote on 08.01.03 in <[email protected]>:

less disgusting. (Also probably needs at least ten (maybe a hundred) times less code, including the kernel code, which plays a big part in the "disgusting" value.)

MfG Kai

From: Linus Torvalds <[email protected]>
Date: Wed, 8 Jan 2003 12:28:23 -0800 (PST)

Don't add stupid bloat to the kernel because somebody is silly enough to care about a 32-bit oprofile working with a 64-bit kernel.

Being that 32-bit is the primary (and in many ways, ONLY) userland for at least 2 64-bit kernel platforms, I think this does matter.

We're exporting an int to userland, what kind of bloat is that really?

Nope.

System binaries match the kernel. It's as easy as that. So what if 90% of the user binaries use 32-bit mode because it's smaller and faster? We're talking about a system binary that is _very_ intimate with the kernel.

Just make it a compile-time option and be done with it.

Linus

From: Linus Torvalds <[email protected]>
Date: Wed, 8 Jan 2003 15:04:05 -0800 (PST)

System binaries match the kernel. It's as easy as that. So what if 90% of the user binaries use 32-bit mode because it's smaller and faster? We're talking about a system binary that is _very_ intimate with the kernel.

oprofile can perfectly legitimately be used to monitor 32-bit binaries running on under a 64-bit kernel environment. In fact I expect such exercises to be very instructive. Anton Blanchard has done this already on ppc64.

And being that 64-bit sparc systems run several orders of magnitude faster than 32-bit ones, I think I'd prefer to oprofile 32-bit programs on sparc64 boxes :-)

Hey, if this is so distasteful we could just add a sys_kernel_pointer_size() to sparc64 and ppc64 and be done with it. The other choice, as mentioned, is to make every platform use u64's in the tables.

That's not the _point_.

Oprofile is a system binary, and as such you might as well use a 64-bit oprofile.

Of y ou can use am /etc/systype file that contains information.

BUT WE DON'T ADD CRAP TO THE KERNEL!

That's final.

Linus

From: Linus Torvalds <[email protected]>
Date: Wed, 8 Jan 2003 16:02:24 -0800 (PST)

Or you can use an /etc/systype file that contains information.

That sounds fine to me.

A funny way to initialize this could be by reading System.map and seeing how many significant hexidecimal digits are used to list the kernel symbol addresses :-)

Don't try it, the perversity of MIPS will break you :)

Just to clarify something that I saw getting lost in this discussion:
Oprofile doesn't need to become built as a 64-bit binary, just configured to accept 64-bit kernels. So this doesn't rule out using a 32-bit oprofile (i.e. not needing a 64-bit libc) on a 64-bit kernel. It just means that we need to specify it somehow.

John, speaking of MIPS perversity: MIPS64 kernels can come in ELF32 files. So you may just want to make this a configure-time option.

Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From: Daniel Jacobowitz <[email protected]>
Date: Wed, 8 Jan 2003 23:00:25 -0500

Just to clarify something that I saw getting lost in this discussion:
Oprofile doesn't need to become built as a 64-bit binary, just configured to accept 64-bit kernels. So this doesn't rule out using a 32-bit oprofile (i.e. not needing a 64-bit libc) on a 64-bit kernel. It just means that we need to specify it somehow.

That's right, indeed. And furthermore, I'm willing to eat the 64-bit overhead for all sparc builds. :)

pkirchner has informed me /proc/kcore returns the correct information in this case on MIPS, and I've also received x86-32/64 confirmation.

64-bit in 32-bit ELF: <pkirchner:#mipslinux> it does say abi=674 mips1 not 32bitmode not fp32
DecStation 5000/200: /proc/kcore: file format elf32-tradlittlemips

Bill

s/the kernel/the booted kernel/ in that. Isn't the reason for wanting this information because it isn't (necessarily) constant? You could rebuild the tools that care at boot time, with configuration options, but you still have to be able to get the information to do the rebuild.

Rather than fight this battle repeatedly, is there some way to make information like this available at run time, in some more reliable way than uname, so that useful tools could simply configure themselves.

Depending on the kernel and all the tools to set things like this via configurations is less robust than providing a way for the applications to tell for certain the environment. There are not all that many values to check, so perhaps having a single way to make them all available is desirable. Like various config options for extra checking in kernel builds, in some cases reliability justifies the overhead.

I'm not making any suggestings on how to do this, /proc certainly makes the information readily available to shell/perl scripts, some magic value to sysconf? Whatever, this is not the first time someone has wanted to be able to access config information, a good solution in one place might be appropriate.

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.