[PATCH] /proc/sys/kernel/pointer_size

[PATCH] /proc/sys/kernel/pointer_size

[John Levon]

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
--- linux-linus/include/linux/sysctl.h	2003-01-03 02:59:14.000000000 +0000
+++ linux/include/linux/sysctl.h	2003-01-03 03:14:44.000000000 +0000
@@ -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
--- linux-linus/kernel/sysctl.c	2002-12-16 04:09:26.000000000 +0000
+++ linux/kernel/sysctl.c	2002-12-16 04:13:58.000000000 +0000
@@ -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},

Re: [PATCH] /proc/sys/kernel/pointer_size

[Linus Torvalds]

On Wed, 8 Jan 2003, John Levon wrote:
> 
> 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

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

Re: [PATCH] /proc/sys/kernel/pointer_size

[John Levon]

On Wed, Jan 08, 2003 at 12:28:23PM -0800, Linus Torvalds wrote:

> 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

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.

> or could even be a user program config file option.

Eww.

> 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. 

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

Re: [PATCH] /proc/sys/kernel/pointer_size

[Linus Torvalds]

On Wed, 8 Jan 2003, John Levon wrote:
> On Wed, Jan 08, 2003 at 12:28:23PM -0800, Linus Torvalds wrote:
> 
> > 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
> 
> 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.

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

> > or could even be a user program config file option.
> 
> Eww.

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.

> 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.

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

Re: [PATCH] /proc/sys/kernel/pointer_size

[David S. Miller]

   From: Linus Torvalds <torvalds@transmeta.com>
   Date: Wed, 8 Jan 2003 13:03:14 -0800 (PST)

   On Wed, 8 Jan 2003, John Levon wrote:
   > 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.
   
   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.

Re: [PATCH] /proc/sys/kernel/pointer_size

[John Levon]

On Wed, Jan 08, 2003 at 01:03:14PM -0800, Linus Torvalds wrote:

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

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...

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

Modules aren't in userspace.

> 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.

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

Re: [PATCH] /proc/sys/kernel/pointer_size

[Kai Henningsen]

torvalds@transmeta.com (Linus Torvalds)  wrote on 08.01.03 in <Pine.LNX.4.44.0301081300200.1497-100000@home.transmeta.com>:

> On Wed, 8 Jan 2003, John Levon wrote:
> > On Wed, Jan 08, 2003 at 12:28:23PM -0800, Linus Torvalds wrote:

> > > or could even be a user program config file option.
> >
> > Eww.
>
> And it's less disgusting than adding a kernel hack for it?

>From my point of view as both user and programmer: about a hundred times  
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

Re: [PATCH] /proc/sys/kernel/pointer_size

[David S. Miller]

   From: Linus Torvalds <torvalds@transmeta.com>
   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?

Re: [PATCH] /proc/sys/kernel/pointer_size

[Linus Torvalds]

On Wed, 8 Jan 2003, David S. Miller wrote:
>    
> 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.

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

Re: [PATCH] /proc/sys/kernel/pointer_size

[David S. Miller]

   From: Linus Torvalds <torvalds@transmeta.com>
   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.

Re: [PATCH] /proc/sys/kernel/pointer_size

[Linus Torvalds]

On Wed, 8 Jan 2003, David S. Miller wrote:
>    
> 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.

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

Re: [PATCH] /proc/sys/kernel/pointer_size

[David S. Miller]

   From: Linus Torvalds <torvalds@transmeta.com>
   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 :-)

Re: [PATCH] /proc/sys/kernel/pointer_size

[Daniel Jacobowitz]

On Wed, Jan 08, 2003 at 04:03:52PM -0800, David S. Miller wrote:
>    From: Linus Torvalds <torvalds@transmeta.com>
>    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

Re: [PATCH] /proc/sys/kernel/pointer_size

[David S. Miller]

   From: Daniel Jacobowitz <dan@debian.org>
   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. :)

Re: [PATCH] /proc/sys/kernel/pointer_size

[William Lee Irwin III]

On Wed, Jan 08, 2003 at 04:03:52PM -0800, David S. Miller wrote:
>> 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 :-)

On Wed, Jan 08, 2003 at 11:00:25PM -0500, Daniel Jacobowitz wrote:
> 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.

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

Re: [PATCH] /proc/sys/kernel/pointer_size

[Bill Davidsen]

On Wed, 8 Jan 2003, Linus Torvalds wrote:

> 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. 

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 <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.