[PATCH] 2.5.68 FUTEX support should be optional

[PATCH] 2.5.68 FUTEX support should be optional

[Christopher Hoover]

Not everyone needs futex support, so it should be optional.  This is
needed for small platforms.

-ch
mailto:ch(at)murgatroid.com
mailto:ch(at)hpl.hp.com

diff -X dontdiff.txt -Naurp linux-2.5.68-rmk1/kernel/Makefile linux-2.5.68-rmk1-ceiva1/kernel/Makefile
--- linux-2.5.68-rmk1/kernel/Makefile	2003-04-19 19:48:55.000000000 -0700
+++ linux-2.5.68-rmk1-ceiva1/kernel/Makefile	2003-05-13 20:58:54.000000000 -0700
@@ -5,9 +5,10 @@
 obj-y     = sched.o fork.o exec_domain.o panic.o printk.o profile.o \
 	    exit.o itimer.o time.o softirq.o resource.o \
 	    sysctl.o capability.o ptrace.o timer.o user.o \
-	    signal.o sys.o kmod.o workqueue.o futex.o pid.o \
+	    signal.o sys.o kmod.o workqueue.o pid.o \
 	    rcupdate.o intermodule.o extable.o params.o posix-timers.o
 
+obj-$(CONFIG_FUTEXT) += futex.o
 obj-$(CONFIG_GENERIC_ISA_DMA) += dma.o
 obj-$(CONFIG_SMP) += cpu.o
 obj-$(CONFIG_UID16) += uid16.o
diff -X dontdiff.txt -Naurp linux-2.5.68-rmk1/kernel/sys.c linux-2.5.68-rmk1-ceiva1/kernel/sys.c
--- linux-2.5.68-rmk1/kernel/sys.c	2003-04-19 19:48:51.000000000 -0700
+++ linux-2.5.68-rmk1-ceiva1/kernel/sys.c	2003-05-13 21:06:02.000000000 -0700
@@ -226,6 +226,7 @@ cond_syscall(sys_shutdown)
 cond_syscall(sys_sendmsg)
 cond_syscall(sys_recvmsg)
 cond_syscall(sys_socketcall)
+cond_syscall(sys_futex)
 
 static int set_one_prio(struct task_struct *p, int niceval, int error)
 {
diff -X dontdiff.txt -Naurp linux-2.5.68-rmk1/init/Kconfig linux-2.5.68-rmk1-ceiva1/init/Kconfig
--- linux-2.5.68-rmk1/init/Kconfig	2003-04-19 19:50:38.000000000 -0700
+++ linux-2.5.68-rmk1-ceiva1/init/Kconfig	2003-05-13 21:25:39.000000000 -0700
@@ -108,8 +108,14 @@ config LOG_BUF_SHIFT
 		     13 =>  8 KB
 		     12 =>  4 KB
 
-endmenu
 
+config FUTEX
+       bool "Futex support"
+       default y
+       ---help---
+       Say Y if you want support for Fast Userspace Mutexes (Futexes).
+
+endmenu
 
 menu "Loadable module support"
 

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Christoph Hellwig]

On Tue, May 13, 2003 at 09:32:07PM -0700, Christopher Hoover wrote:
> Not everyone needs futex support, so it should be optional.  This is
> needed for small platforms.

Looks good.  I think you want to disable it unconditionally for !CONFIG_MMU.

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Miles Bader]

Christoph Hellwig <hch@infradead.org> writes:
> > Not everyone needs futex support, so it should be optional.  This is
> > needed for small platforms.
> 
> Looks good.  I think you want to disable it unconditionally for !CONFIG_MMU.

Are futexes unusable without an MMU (I don't know anything about the
implementation)?

Thanks,

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Christoph Hellwig]

On Wed, May 14, 2003 at 03:20:54PM +0900, Miles Bader wrote:
> Are futexes unusable without an MMU (I don't know anything about the
> implementation)?

The futex implementation relies heavily on follow_page() which is stubbed out
for nommu builds.

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Andrew Morton]

Christoph Hellwig <hch@infradead.org> wrote:
>
> On Tue, May 13, 2003 at 09:32:07PM -0700, Christopher Hoover wrote:
> > Not everyone needs futex support, so it should be optional.  This is
> > needed for small platforms.
> 
> Looks good.  I think you want to disable it unconditionally for !CONFIG_MMU.
> 

It needs some changes for non-ia32.


diff -puN init/Kconfig~CONFIG_FUTEX init/Kconfig
--- 25-power4/init/Kconfig~CONFIG_FUTEX	2003-05-13 22:12:34.000000000 -0700
+++ 25-power4-akpm/init/Kconfig	2003-05-13 22:12:34.000000000 -0700
@@ -108,8 +108,14 @@ config LOG_BUF_SHIFT
 		     13 =>  8 KB
 		     12 =>  4 KB
 
-endmenu
 
+config FUTEX
+       bool "Futex support"
+       default y
+       ---help---
+       Say Y if you want support for Fast Userspace Mutexes (Futexes).
+
+endmenu
 
 menu "Loadable module support"
 
diff -puN kernel/Makefile~CONFIG_FUTEX kernel/Makefile
--- 25-power4/kernel/Makefile~CONFIG_FUTEX	2003-05-13 22:12:34.000000000 -0700
+++ 25-power4-akpm/kernel/Makefile	2003-05-13 22:15:09.000000000 -0700
@@ -5,9 +5,10 @@
 obj-y     = sched.o fork.o exec_domain.o panic.o printk.o profile.o \
 	    exit.o itimer.o time.o softirq.o resource.o \
 	    sysctl.o capability.o ptrace.o timer.o user.o \
-	    signal.o sys.o kmod.o workqueue.o futex.o pid.o \
+	    signal.o sys.o kmod.o workqueue.o pid.o \
 	    rcupdate.o intermodule.o extable.o params.o posix-timers.o
 
+obj-$(CONFIG_FUTEX) += futex.o
 obj-$(CONFIG_GENERIC_ISA_DMA) += dma.o
 obj-$(CONFIG_SMP) += cpu.o
 obj-$(CONFIG_LOCKMETER) += lockmeter.o
diff -puN kernel/sys.c~CONFIG_FUTEX kernel/sys.c
--- 25-power4/kernel/sys.c~CONFIG_FUTEX	2003-05-13 22:12:34.000000000 -0700
+++ 25-power4-akpm/kernel/sys.c	2003-05-13 22:12:34.000000000 -0700
@@ -228,6 +228,7 @@ cond_syscall(sys_shutdown)
 cond_syscall(sys_sendmsg)
 cond_syscall(sys_recvmsg)
 cond_syscall(sys_socketcall)
+cond_syscall(sys_futex)
 
 static int set_one_prio(struct task_struct *p, int niceval, int error)
 {
diff -puN kernel/compat.c~CONFIG_FUTEX kernel/compat.c
--- 25-power4/kernel/compat.c~CONFIG_FUTEX	2003-05-13 22:17:56.000000000 -0700
+++ 25-power4-akpm/kernel/compat.c	2003-05-13 22:27:29.000000000 -0700
@@ -211,11 +211,10 @@ asmlinkage long compat_sys_sigprocmask(i
 	return ret;
 }
 
-extern long do_futex(unsigned long, int, int, unsigned long);
-
 asmlinkage long compat_sys_futex(u32 *uaddr, int op, int val,
 		struct compat_timespec *utime)
 {
+#ifdef CONFIG_FUTEX
 	struct timespec t;
 	unsigned long timeout = MAX_SCHEDULE_TIMEOUT;
 
@@ -225,6 +224,9 @@ asmlinkage long compat_sys_futex(u32 *ua
 		timeout = timespec_to_jiffies(&t) + 1;
 	}
 	return do_futex((unsigned long)uaddr, op, val, timeout);
+#else
+	return -ENOSYS;
+#endif
 }
 
 asmlinkage long sys_setrlimit(unsigned int resource, struct rlimit *rlim);
diff -puN include/linux/futex.h~CONFIG_FUTEX include/linux/futex.h
--- 25-power4/include/linux/futex.h~CONFIG_FUTEX	2003-05-13 22:18:20.000000000 -0700
+++ 25-power4-akpm/include/linux/futex.h	2003-05-13 22:22:21.000000000 -0700
@@ -8,4 +8,6 @@
 
 extern asmlinkage long sys_futex(u32 __user *uaddr, int op, int val, struct timespec __user *utime);
 
+long do_futex(unsigned long uaddr, int op, int val, unsigned long timeout);
+
 #endif

_

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Christoph Hellwig]

On Tue, May 13, 2003 at 11:32:19PM -0700, Andrew Morton wrote:
>  asmlinkage long compat_sys_futex(u32 *uaddr, int op, int val,
>  		struct compat_timespec *utime)
>  {
> +#ifdef CONFIG_FUTEX
>  	struct timespec t;
>  	unsigned long timeout = MAX_SCHEDULE_TIMEOUT;
>  
> @@ -225,6 +224,9 @@ asmlinkage long compat_sys_futex(u32 *ua
>  		timeout = timespec_to_jiffies(&t) + 1;
>  	}
>  	return do_futex((unsigned long)uaddr, op, val, timeout);
> +#else
> +	return -ENOSYS;
> +#endif

Please make compat_sys_futex a cond_syscall, too.

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Christopher Hoover]

On Wed, May 14, 2003 at 07:14:46AM +0100, Christoph Hellwig wrote:
> On Tue, May 13, 2003 at 09:32:07PM -0700, Christopher Hoover wrote:
> > Not everyone needs futex support, so it should be optional.  This is
> > needed for small platforms.
> 
> Looks good.  I think you want to disable it unconditionally for !CONFIG_MMU.

Good point.  

Here it is again with the config change.  The previous version also had
had a Makefile typo.  Plus a cond_syscall for compat_sys_futex to make
it work for CONFIG_COMPAT (untested), as pointed out by akpm.

diff --exclude=drivers --exclude=net --exclude=sound -X dontdiff.txt -Naurp linux-2.5.69.orig/include/linux/futex.h linux-2.5.69/include/linux/futex.h
--- linux-2.5.69.orig/include/linux/futex.h	2003-05-04 16:53:33.000000000 -0700
+++ linux-2.5.69/include/linux/futex.h	2003-05-14 00:17:25.000000000 -0700
@@ -8,4 +8,6 @@
 
 extern asmlinkage long sys_futex(u32 *uaddr, int op, int val, struct timespec *utime);
 
+long do_futex(unsigned long, int, int, unsigned long);
+
 #endif
diff --exclude=drivers --exclude=net --exclude=sound -X dontdiff.txt -Naurp linux-2.5.69.orig/init/Kconfig linux-2.5.69/init/Kconfig
--- linux-2.5.69.orig/init/Kconfig	2003-05-04 16:53:37.000000000 -0700
+++ linux-2.5.69/init/Kconfig	2003-05-14 00:03:05.000000000 -0700
@@ -108,8 +108,15 @@ config LOG_BUF_SHIFT
 		     13 =>  8 KB
 		     12 =>  4 KB
 
-endmenu
 
+config FUTEX
+       bool "Futex support"
+       depends on MMU
+       default y
+       ---help---
+       Say Y if you want support for Fast Userspace Mutexes (Futexes).
+
+endmenu
 
 menu "Loadable module support"
 
diff --exclude=drivers --exclude=net --exclude=sound -X dontdiff.txt -Naurp linux-2.5.69.orig/kernel/Makefile linux-2.5.69/kernel/Makefile
--- linux-2.5.69.orig/kernel/Makefile	2003-05-04 16:53:07.000000000 -0700
+++ linux-2.5.69/kernel/Makefile	2003-05-14 00:02:30.000000000 -0700
@@ -5,9 +5,10 @@
 obj-y     = sched.o fork.o exec_domain.o panic.o printk.o profile.o \
 	    exit.o itimer.o time.o softirq.o resource.o \
 	    sysctl.o capability.o ptrace.o timer.o user.o \
-	    signal.o sys.o kmod.o workqueue.o futex.o pid.o \
+	    signal.o sys.o kmod.o workqueue.o pid.o \
 	    rcupdate.o intermodule.o extable.o params.o posix-timers.o
 
+obj-$(CONFIG_FUTEX) += futex.o
 obj-$(CONFIG_GENERIC_ISA_DMA) += dma.o
 obj-$(CONFIG_SMP) += cpu.o
 obj-$(CONFIG_UID16) += uid16.o
diff --exclude=drivers --exclude=net --exclude=sound -X dontdiff.txt -Naurp linux-2.5.69.orig/kernel/compat.c linux-2.5.69/kernel/compat.c
--- linux-2.5.69.orig/kernel/compat.c	2003-05-04 16:53:29.000000000 -0700
+++ linux-2.5.69/kernel/compat.c	2003-05-14 00:17:32.000000000 -0700
@@ -211,8 +211,7 @@ asmlinkage long compat_sys_sigprocmask(i
 	return ret;
 }
 
-extern long do_futex(unsigned long, int, int, unsigned long);
-
+#ifdef CONFIG_FUTEX
 asmlinkage long compat_sys_futex(u32 *uaddr, int op, int val,
 		struct compat_timespec *utime)
 {
@@ -226,6 +225,7 @@ asmlinkage long compat_sys_futex(u32 *ua
 	}
 	return do_futex((unsigned long)uaddr, op, val, timeout);
 }
+#endif
 
 asmlinkage long sys_setrlimit(unsigned int resource, struct rlimit *rlim);
 
diff --exclude=drivers --exclude=net --exclude=sound -X dontdiff.txt -Naurp linux-2.5.69.orig/kernel/sys.c linux-2.5.69/kernel/sys.c
--- linux-2.5.69.orig/kernel/sys.c	2003-05-04 16:53:02.000000000 -0700
+++ linux-2.5.69/kernel/sys.c	2003-05-14 00:12:07.000000000 -0700
@@ -226,6 +226,8 @@ cond_syscall(sys_shutdown)
 cond_syscall(sys_sendmsg)
 cond_syscall(sys_recvmsg)
 cond_syscall(sys_socketcall)
+cond_syscall(sys_futex)
+cond_syscall(compat_sys_futex)
 
 static int set_one_prio(struct task_struct *p, int niceval, int error)
 {

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christopher Hoover wrote:

> +config FUTEX
> +       bool "Futex support"
> +       depends on MMU
> +       default y
> +       ---help---
> +       Say Y if you want support for Fast Userspace Mutexes (Futexes).
> +
> +endmenu

If this is what is wanted (and I don't really think it's useful is a MMU
is available) you should explain the consequences in the help text.
Basically, no current and future glibc version has the slightest chance
of working.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+wpbO2ijCOnn/RHQRAj18AJ9uyaEouJILT2Nk3RmxL9QA9xfiYwCeMLOg
Egve3dwd9NOcBRGPgT062Nw=
=cnrE
-----END PGP SIGNATURE-----

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Dave Jones]

On Wed, May 14, 2003 at 12:19:42PM -0700, Ulrich Drepper wrote:

 > If this is what is wanted (and I don't really think it's useful is a MMU
 > is available) you should explain the consequences in the help text.
 > Basically, no current and future glibc version has the slightest chance
 > of working.

That seems to imply that the current glibc makes futexes mandatory,
which surely isn't the case or we'd not be able to run with 2.4 and earlier
kernels.

		Dave

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave Jones wrote:

> That seems to imply that the current glibc makes futexes mandatory,
> which surely isn't the case or we'd not be able to run with 2.4 and earlier
> kernels.

Current == current development.  LinuxThreads is not developed anymore
and with nptl futexes are mandatory.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+wpyy2ijCOnn/RHQRAv88AJ4mZDNFyre2J6Pku7jkE2JSvV4aBgCgufYG
70N4RNLFQzDNIk3id3UHJUk=
=LqUF
-----END PGP SIGNATURE-----

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Linus Torvalds]

On Wed, 14 May 2003, Ulrich Drepper wrote:
> 
> Current == current development.  LinuxThreads is not developed anymore
> and with nptl futexes are mandatory.

Yes, I'm also not very eager to make "core functionality" a config option. 
The confusion with the INPUT layer config options was mighty, and none of 
it pleasant. And the *BSD's have historically had totally stupid problems 
with programs like Wine etc requireing kernel recompiles just because they 
made code functionality like vm86 mode or LDT support be a config option.

I don't see the point in dropping futexes except perhaps in a very 
controlled embedded environment, but if that is the case, then a PC config 
should just force it to "y" and not even ask the user. 

We absolutely do NOT want the situation where a program will not work just 
because the user forgot some config option that mostly isn't needed.

And futexes _are_ going to be needed. Any sane high-performance threading 
implementation _will_ use them. No ifs, buts or maybe's.

		Linus

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Andrew Morton]

Linus Torvalds <torvalds@transmeta.com> wrote:
>
> I don't see the point in dropping futexes except perhaps in a very 
> controlled embedded environment, but if that is the case, then a PC config 
> should just force it to "y" and not even ask the user.

How about we place these things under an additional CONFIG_TINY menu with
big fat warnings on it.  

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Davide Libenzi]

On Wed, 14 May 2003, Linus Torvalds wrote:

>
> On Wed, 14 May 2003, Ulrich Drepper wrote:
> >
> > Current == current development.  LinuxThreads is not developed anymore
> > and with nptl futexes are mandatory.
>
> Yes, I'm also not very eager to make "core functionality" a config option.
> The confusion with the INPUT layer config options was mighty, and none of
> it pleasant. And the *BSD's have historically had totally stupid problems
> with programs like Wine etc requireing kernel recompiles just because they
> made code functionality like vm86 mode or LDT support be a config option.
>
> I don't see the point in dropping futexes except perhaps in a very
> controlled embedded environment, but if that is the case, then a PC config
> should just force it to "y" and not even ask the user.
>
> We absolutely do NOT want the situation where a program will not work just
> because the user forgot some config option that mostly isn't needed.

Not only. Like Ulrich was saying, the config documentation should heavily
warn the wild config guy about the consequences of a 'NO' over there.



- Davide

Re: [PATCH] 2.5.68 FUTEX support should be optional

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.55.0305141342030.4539@bigblue.dev.mcafeelabs.com>
By author:    Davide Libenzi <davidel@xmailserver.org>
In newsgroup: linux.dev.kernel
> 
> Not only. Like Ulrich was saying, the config documentation should heavily
> warn the wild config guy about the consequences of a 'NO' over there.
> 

How about creating a master option like we have for experimental?
Something like "Allow removal of essential components?" (CONFIG_EMBEDDED)

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Davide Libenzi]

On Wed, 14 May 2003, H. Peter Anvin wrote:

> Followup to:  <Pine.LNX.4.55.0305141342030.4539@bigblue.dev.mcafeelabs.com>
> By author:    Davide Libenzi <davidel@xmailserver.org>
> In newsgroup: linux.dev.kernel
> >
> > Not only. Like Ulrich was saying, the config documentation should heavily
> > warn the wild config guy about the consequences of a 'NO' over there.
> >
>
> How about creating a master option like we have for experimental?
> Something like "Allow removal of essential components?" (CONFIG_EMBEDDED)

I'd agree. Not showing them at all for std configurations is even better.


- Davide

RE: [PATCH] 2.5.68 FUTEX support should be optional

[Christopher Hoover]

> I don't see the point in dropping futexes except
> perhaps in a very controlled embedded environment,
> but if that is the case,  then a PC config 
> should just force it to "y" and not even ask the user. 

We could do this (et al) under CONFIG_TINY, if you would prefer.


> We absolutely do NOT want the situation where
> a program will not work just because the user forgot
> some config option that mostly isn't needed.

This a specious argument.  There are many ways one can configure a
kernel that will make it fail to boot or run user space properly.
There's no getting around knowing what it is your configuring in and
out.

Note that I set the default to Y.  I also agree that I could have been
more verbose in the help string.

> And futexes _are_ going to be needed. Any sane high-performance
threading 
> implementation _will_ use them. No ifs, buts or maybe's.

All big machines, sure.  All small machines, it depends.  All the (user)
world is not glibc.

-ch

RE: [PATCH] 2.5.68 FUTEX support should be optional

[Linus Torvalds]

On Wed, 14 May 2003, Christopher Hoover wrote:
> 
> This a specious argument.  There are many ways one can configure a
> kernel that will make it fail to boot or run user space properly.

Not very many, and some of them have been removed.

For example, CONFIG_FILTER no longer exists. Why? Because it was too easy 
to create a kernel on which dhcp no longer worked, and the advantage of 
making it a config option was minimal.

Yes, CONFIG_NET and CONFIG_SYSVIPC are still there. And everybody turns
them on, and they really are only useful for very embedded platforms. But
at least turning them off saves huge amounts of memory for those
platforms, something that isn't true of futexes.

Apart from those options? Not many I can see. CONFIG_PACKET perhaps,
although even that tends to break only very specialized applications.

The rule should _not_ be "what can we make optional". The rule should be 
"this must be made optional because there is a big advantage doing it that 
way, and it's specialized".

Futexes may be specialized today, but that's only because you have to run 
a modern glibc to see them. But once you do that, they are not specialized 
at all.

Btw, the fact that futexes don't work without CONFIG_MMU is a bug not in
futexes, but it the MMU-less code. The no-mmu version of "follow_page" is
just wrong and badly implemented, and there's nothing to say that futexes
aren't useful without a MMU. 

			Linus

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Miles Bader]

Linus Torvalds <torvalds@transmeta.com> writes:
> Btw, the fact that futexes don't work without CONFIG_MMU is a bug not in
> futexes, but it the MMU-less code. The no-mmu version of "follow_page" is
> just wrong and badly implemented, and there's nothing to say that futexes
> aren't useful without a MMU. 

Ah, this is what I was hoping to hear...

-miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Ingo Oeser]

Hi,

On Wed, May 14, 2003 at 12:19:42PM -0700, Ulrich Drepper wrote:
[CONFIG_FUTEX]
> If this is what is wanted (and I don't really think it's useful is a MMU
> is available) you should explain the consequences in the help text.
> Basically, no current and future glibc version has the slightest chance
> of working.

Is this also the case, if I don't want threading at all on my
system? Does glibc still have a seperate static library for this,
or should I revert to dietlibc in these cases?

Thanks & Regards

Ingo Oeser

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ingo Oeser wrote:

> Is this also the case, if I don't want threading at all on my
> system? Does glibc still have a seperate static library for this,

This has nothing to do with static linking or not.

glibc, when compiled with nptl, will always include uses of futexes.
But since there is no contention and the fast path is entirely handled
at userlevel, the actual kernel functionality is not required.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+w9JH2ijCOnn/RHQRApR/AKCHcHAUsXfz834/ZH0z3iQneNMh4gCfUMzA
RB4+2XbfsJZXpkWQUx5NXPY=
=XGtI
-----END PGP SIGNATURE-----

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Bill Davidsen]

On Thu, 15 May 2003, Ulrich Drepper wrote:

> Ingo Oeser wrote:
> 
> > Is this also the case, if I don't want threading at all on my
> > system? Does glibc still have a seperate static library for this,
> 
> This has nothing to do with static linking or not.
> 
> glibc, when compiled with nptl, will always include uses of futexes.
> But since there is no contention and the fast path is entirely handled
> at userlevel, the actual kernel functionality is not required.

He didn't say static linking he said static library. I assume he meant a
.a lib instead of a .so lib. One which has elements which are made part of
the executable instead of being part of a shared library.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bill Davidsen wrote:

> He didn't say static linking he said static library. I assume he meant a
> .a lib instead of a .so lib. One which has elements which are made part of
> the executable instead of being part of a shared library.

And in what way does this not match what I say?  The content of the DSO
and the archive is identical functionality-wise and therefore none of
this ever has any influence on whether futexes are used or not.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+w9ls2ijCOnn/RHQRAsfAAJ9sSbudcXdNSHYAB6ICm/fXWRhuQQCgqmMD
cwxSzwuFEeeS6ACGonakUy8=
=+/L9
-----END PGP SIGNATURE-----

RE: [PATCH] 2.5.68 FUTEX support should be optional

[Christopher Hoover]

> Is this also the case, if I don't want threading at all on my
> system? Does glibc still have a seperate static library for this,
> or should I revert to dietlibc in these cases?

I'm using the most excellent uClibc, which has a configuration option
for POSIX threads.

-ch

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Chuck Ebbert]

hpa wrote:

> How about creating a master option like we have for experimental?
> Something like "Allow removal of essential components?" (CONFIG_EMBEDDED)

  ...and that just enables another option: "REALLY allow removal of
essential components?" (CONFIG_REALLY_EMBEDDED)

 :)

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Carl-Daniel Hailfinger]

Chuck Ebbert wrote:
> hpa wrote:
> 
> 
>>How about creating a master option like we have for experimental?
>>Something like "Allow removal of essential components?" (CONFIG_EMBEDDED)
> 
> 
>   ...and that just enables another option: "REALLY allow removal of
> essential components?" (CONFIG_REALLY_EMBEDDED)
> 
>  :)

Reminds me of CONFIG_MORON back in December 2000

-dep_mbool '  NTFS write support (DANGEROUS)' CONFIG_NTFS_RW
$CONFIG_NTFS_FS $CONFIG_EXPERIMENTAL
+dep_mbool '  NTFS write support (DANGEROUS)' CONFIG_MORON
$CONFIG_NTFS_FS $CONFIG_EXPERIMENTAL
+dep_bool  '    Are you sure?  I hope you dont care about your NTFS
filesystems' CONFIG_NTFS_RW $CONFIG_MORON

;)


Carl-Daniel
-- 
And the mailer looked at the patch and, behold, it was good. And the
mailer decided to wrap the patch.

RE: [PATCH] 2.5.68 FUTEX support should be optional

[Perez-Gonzalez, Inaky]

> From: Christopher Hoover [mailto:ch@murgatroid.com]
> 
> On Wed, May 14, 2003 at 07:14:46AM +0100, Christoph Hellwig wrote:
> > On Tue, May 13, 2003 at 09:32:07PM -0700, Christopher Hoover wrote:
> > > Not everyone needs futex support, so it should be optional.  This is
> > > needed for small platforms.
> >
> > Looks good.  I think you want to disable it unconditionally for
!CONFIG_MMU.
> 
> Good point.
> 
> Here it is again with the config change.  The previous version also had
> had a Makefile typo.  Plus a cond_syscall for compat_sys_futex to make
> it work for CONFIG_COMPAT (untested), as pointed out by akpm.

How does this affect mm_release() in fork.c? there is a call to sys_futex();
if you make it conditional, will it break anything in there?

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Andrew Morton]

"Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@intel.com> wrote:
>
> How does this affect mm_release() in fork.c? there is a call to sys_futex();
> if you make it conditional, will it break anything in there?

Via linker magic, mm_release() will simply call sys_ni_syscall() instead.  

(I ran a futex-free ppc64 kernel.  It worked.)

RE: [PATCH] 2.5.68 FUTEX support should be optional

[Christopher Hoover]

> "Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@intel.com> wrote:
> >
> > How does this affect mm_release() in fork.c? there is a 
> call to sys_futex();
> > if you make it conditional, will it break anything in there?
> 
> Via linker magic, mm_release() will simply call 
> sys_ni_syscall() instead.  
> 
> (I ran a futex-free ppc64 kernel.  It worked.)

Yep.  I'm run an ARM kernel as well.  Works fine.

-ch

RE: [PATCH] 2.5.68 FUTEX support should be optional

[Linus Torvalds]

On Wed, 14 May 2003, Christopher Hoover wrote:
> > 
> > (I ran a futex-free ppc64 kernel.  It worked.)
> 
> Yep.  I'm run an ARM kernel as well.  Works fine.

And do you guys actually use a recent glibc snapshot? Do you ever expect 
to? Do you ever expect to run a third-party specialized web-server or 
database library? All things that can use futex'es, and probably will. 

I will strongly argue against making futexes conditional, simply because I 
_want_ people to be able to depend on them in modern kernels. I do not 
want developers to fall back on SysV semaphores just because it's too 
painful for them to use the faster alternatives.

		Linus

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Andrew Morton]

Linus Torvalds <torvalds@transmeta.com> wrote:
>
> And do you guys actually use a recent glibc snapshot? Do you ever expect 
>  to?

I believe this effort is more targetted at teeny little embedded gadgets -
devices which are very remote from workstations, desktops and servers.

Presumably the people who are programming such gadgets will know if they
need futexes or not.


We've never clearly addressed the issue of just how far the mainstream
kernel should scale down, and how pluggable the various kernel components
should be.

Retrofitting pluggability is hard (CONFIG_BLOCK_LAYER) but at the very
least, we should make this effort for newly-added components.


Assuming, of course, that we _do_ want to make the mainstream kernel scale
that far down.  It could be argued that this is a role for vendors or other
specialised parties.

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Linus Torvalds]

On Wed, 14 May 2003, Andrew Morton wrote:
> 
> I believe this effort is more targetted at teeny little embedded gadgets -
> devices which are very remote from workstations, desktops and servers.

And even there futexes are (a) faster and (b) smaller than SYSVIPC. So 
assuming you ever want threading in an embedded world (not unlikely at 
all, since things like DVD playback etc are mostly done with threads), you 
want futexes.

> Presumably the people who are programming such gadgets will know if they
> need futexes or not.

Yes. We can make tit a CONFIG option, and then force it to always be "y" 
in the .config file. And then the people who really know and really care 
can turn the "y" to a "n".

		Linus

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Andrew Morton]

Linus Torvalds <torvalds@transmeta.com> wrote:
>
> Yes. We can make tit a CONFIG option, and then force it to always be "y" 
>  in the .config file. And then the people who really know and really care 
>  can turn the "y" to a "n".


I did it the below way.  Or are you suggesting that a manual edit of
.config should be required?   It may not get tested at all that way?



--- 25/init/Kconfig~CONFIG_FUTEX	Wed May 14 12:43:16 2003
+++ 25-akpm/init/Kconfig	Wed May 14 13:06:15 2003
@@ -108,8 +108,17 @@ config LOG_BUF_SHIFT
 		     13 =>  8 KB
 		     12 =>  4 KB
 
+menu "Size reduced kernel"
+
+config FUTEX
+	bool "Futex support"
+	default y
+	---help---
+	Say Y if you want support for Fast Userspace Mutexes (Futexes).
+	WARNING: disabling futex support will probably cause glibc to fail.
 endmenu
 
+endmenu
 
 menu "Loadable module support"
 

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Davide Libenzi]

On Wed, 14 May 2003, Andrew Morton wrote:

> +menu "Size reduced kernel"
> +
> +config FUTEX
> +	bool "Futex support"
> +	default y
> +	---help---
> +	Say Y if you want support for Fast Userspace Mutexes (Futexes).
> +	WARNING: disabling futex support will probably cause glibc to fail.

This should also break kernels with MMUs ( see mm_release ).



- Davide

RE: [PATCH] 2.5.68 FUTEX support should be optional

[Christopher Hoover]

> This should also break kernels with MMUs ( see mm_release ).

I don't believe it does as there's a cond_syscall entry for sys_futex.

More to the point, I'm running with CONFIG_FUTEX=n and it works fine.
I'm up to a whopping 304KiB MemFree with busybox and bluetooth
(hcid/sdpd/hciattach) running.

-ch
mailto:ch(at)hpl.hp.com
mailto:ch(at)murgatroid.com

RE: [PATCH] 2.5.68 FUTEX support should be optional

[Davide Libenzi]

On Wed, 14 May 2003, Christopher Hoover wrote:

>
> > This should also break kernels with MMUs ( see mm_release ).
>
> I don't believe it does as there's a cond_syscall entry for sys_futex.

Yep, you're right cond_syscall does it.



- Davide

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Arnaldo Carvalho de Melo]

Em Wed, May 14, 2003 at 06:39:25PM -0700, Andrew Morton escreveu:
> Linus Torvalds <torvalds@transmeta.com> wrote:
> --- 25/init/Kconfig~CONFIG_FUTEX	Wed May 14 12:43:16 2003
> +++ 25-akpm/init/Kconfig	Wed May 14 13:06:15 2003
> @@ -108,8 +108,17 @@ config LOG_BUF_SHIFT
>  		     13 =>  8 KB
>  		     12 =>  4 KB
>  
> +menu "Size reduced kernel"
> +
> +config FUTEX
> +	bool "Futex support"
> +	default y
> +	---help---
> +	Say Y if you want support for Fast Userspace Mutexes (Futexes).
> +	WARNING: disabling futex support will probably cause glibc to fail.
>  endmenu
>  
> +endmenu

Thanks! With this CONFIG_TINY is born :)

- Arnaldo

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Linus Torvalds]

On Wed, 14 May 2003, Andrew Morton wrote:
> 
> I did it the below way.  Or are you suggesting that a manual edit of
> .config should be required? 

Yes. The same way MMU, UID16 and GENERIC_ISA_DMA is always true on x86. 
You could make it false on some other architecture where it might make 
sense.

		Linus

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Bill Davidsen]

On Wed, 14 May 2003, Andrew Morton wrote:

> Linus Torvalds <torvalds@transmeta.com> wrote:
> >
> > And do you guys actually use a recent glibc snapshot? Do you ever expect 
> >  to?
> 
> I believe this effort is more targetted at teeny little embedded gadgets -
> devices which are very remote from workstations, desktops and servers.
> 
> Presumably the people who are programming such gadgets will know if they
> need futexes or not.
> 
> 
> We've never clearly addressed the issue of just how far the mainstream
> kernel should scale down, and how pluggable the various kernel components
> should be.
> 
> Retrofitting pluggability is hard (CONFIG_BLOCK_LAYER) but at the very
> least, we should make this effort for newly-added components.
> 
> 
> Assuming, of course, that we _do_ want to make the mainstream kernel scale
> that far down.  It could be argued that this is a role for vendors or other
> specialised parties.

Certainly the great effort some vendors put in making the kernel small
doesn't belong in the main kernel. But things which can relatively be made
optional, and I think that means futex, could. I like the idea of a tiny
kernel menu, with some painful detail about what happens if you remove a
feature. In many cases "breaks glibc" isn't an issue.


On Wed, 14 May 2003, Linus Torvalds wrote:

> 
> On Wed, 14 May 2003, Christopher Hoover wrote:
> > > 
> > > (I ran a futex-free ppc64 kernel.  It worked.)
> > 
> > Yep.  I'm run an ARM kernel as well.  Works fine.
> 
> And do you guys actually use a recent glibc snapshot? Do you ever expect 
> to? Do you ever expect to run a third-party specialized web-server or 
> database library? All things that can use futex'es, and probably will. 
> 
> I will strongly argue against making futexes conditional, simply because I 
> _want_ people to be able to depend on them in modern kernels. I do not 
> want developers to fall back on SysV semaphores just because it's too 
> painful for them to use the faster alternatives.

Clearly the call is yours, but if all the optional features with
capability impact are in a single menu, as proposed, then you avoid
having people mess up by doing the removal by hand.

Making it easier to use Linux for small applications seems like a good
thing, although I admit that's an activist rather than a technical point
of view.


On Wed, 14 May 2003, Linus Torvalds wrote:

> 
> On Wed, 14 May 2003, Andrew Morton wrote:
> > 
> > I believe this effort is more targetted at teeny little embedded gadgets -
> > devices which are very remote from workstations, desktops and servers.
> 
> And even there futexes are (a) faster and (b) smaller than SYSVIPC. So 
> assuming you ever want threading in an embedded world (not unlikely at 
> all, since things like DVD playback etc are mostly done with threads), you 
> want futexes.
> 
> > Presumably the people who are programming such gadgets will know if they
> > need futexes or not.
> 
> Yes. We can make tit a CONFIG option, and then force it to always be "y" 
> in the .config file. And then the people who really know and really care 
> can turn the "y" to a "n".

I would say that having it on a "tiny Linux" menu, labeled dangerous,
with an explanatory help message is less likely to cause trouble than
letting people view it as "an undocmented Linux config option to make
the kernel smaller and faster."

If you know what you will break it's less likely to be a surprise.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

RE: [PATCH] 2.5.68 FUTEX support should be optional

[Alan Cox]

On Iau, 2003-05-15 at 02:00, Linus Torvalds wrote:
> I will strongly argue against making futexes conditional, simply because I 
> _want_ people to be able to depend on them in modern kernels. I do not 
> want developers to fall back on SysV semaphores just because it's too 
> painful for them to use the faster alternatives.

In the embedded space being able to chop stuff out makes a lot of sense.
It also encourages people to get modularity right. These are the same
people who already turn SYS5 IPC off as well, as as for glibc, well its
cute but its frequently bigger than the entire flash of the device.

There are arguments in some cases for avoiding the selections (notably
adding a zillion ifdefs to remove something thats utterly trivial) but
providing most users see only

	Remove kernel features for embedded systems (Y/N)

its no more dangerous/hassle than the kernel debug menu

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Valdis.Kletnieks]

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

On Fri, 16 May 2003 22:55:42 BST, Alan Cox said:

> There are arguments in some cases for avoiding the selections (notably
> adding a zillion ifdefs to remove something thats utterly trivial) but
> providing most users see only
> 
> 	Remove kernel features for embedded systems (Y/N)
> 
> its no more dangerous/hassle than the kernel debug menu

OK.. I know I argued against making it visible to the user at all, but if it's
phrased like that, it will at least (hopefully) dissuade everybody who
doesn't know what an embedded system is.

And after all, Linux isn't about dissuading the truly determined, nor is it
about making moral judgements regarding their wizardry/idiocy ratio....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Andrew Morton]

Valdis.Kletnieks@vt.edu wrote:
>
> > 	Remove kernel features for embedded systems (Y/N)
>  > 
>  > its no more dangerous/hassle than the kernel debug menu
> 
>  OK.. I know I argued against making it visible to the user at all, but if it's
>  phrased like that, it will at least (hopefully) dissuade everybody who
>  doesn't know what an embedded system is.
> 
>  And after all, Linux isn't about dissuading the truly determined, nor is it
>  about making moral judgements regarding their wizardry/idiocy ratio....

I'd agree with all that.  I've updated the initial patch thusly:

General setup --->
    [*] Remove kernel features for embedded systems
          Removable kernel features for embedded systems  --->
              [ ] Enable futex support

So enabling CONFIG_EMBEDDED causes the user to be offered CONFIG_FUTEX, and
there are appropriate stern warnings everywhere.


 init/Kconfig          |   24 +++++++++++++++++++++++-
 kernel/Makefile       |    3 ++-
 kernel/compat.c       |    5 +++--
 kernel/sys.c          |    2 ++
 5 files changed, 32 insertions(+), 4 deletions(-)

diff -puN init/Kconfig~CONFIG_FUTEX init/Kconfig
--- 25/init/Kconfig~CONFIG_FUTEX	2003-05-16 19:17:34.000000000 -0700
+++ 25-akpm/init/Kconfig	2003-05-16 19:32:43.000000000 -0700
@@ -108,8 +108,31 @@ config LOG_BUF_SHIFT
 		     13 =>  8 KB
 		     12 =>  4 KB
 
+
+config EMBEDDED
+	bool "Remove kernel features for embedded systems"
+	default n
+	help
+	  This option allows certain base kernel features to be removed from
+	  the build.  This is for specialized environments which can tolerate
+	  a "non-standard" kernel.  Only use this if you really know what you
+	  are doing.
+
+menu "Removable kernel features for embedded systems"
+	depends on EMBEDDED
+
+config FUTEX
+	bool "Enable futex support"
+	depends on EMBEDDED
+	default y
+	help
+	  Disabling this option will cause the kernel to be built without
+	  support for "fast userspace mutexes".  The resulting kernel may not
+	  run glibc-based applications correctly.
+
 endmenu
 
+endmenu
 
 menu "Loadable module support"
 
@@ -181,4 +204,3 @@ config KMOD
 	  in <file:Documentation/kmod.txt>.
 
 endmenu
-
diff -puN kernel/Makefile~CONFIG_FUTEX kernel/Makefile
--- 25/kernel/Makefile~CONFIG_FUTEX	2003-05-16 19:17:34.000000000 -0700
+++ 25-akpm/kernel/Makefile	2003-05-16 19:17:34.000000000 -0700
@@ -5,9 +5,10 @@
 obj-y     = sched.o fork.o exec_domain.o panic.o printk.o profile.o \
 	    exit.o itimer.o time.o softirq.o resource.o \
 	    sysctl.o capability.o ptrace.o timer.o user.o \
-	    signal.o sys.o kmod.o workqueue.o futex.o pid.o \
+	    signal.o sys.o kmod.o workqueue.o pid.o \
 	    rcupdate.o intermodule.o extable.o params.o posix-timers.o
 
+obj-$(CONFIG_FUTEX) += futex.o
 obj-$(CONFIG_GENERIC_ISA_DMA) += dma.o
 obj-$(CONFIG_SMP) += cpu.o
 obj-$(CONFIG_LOCKMETER) += lockmeter.o
diff -puN kernel/sys.c~CONFIG_FUTEX kernel/sys.c
--- 25/kernel/sys.c~CONFIG_FUTEX	2003-05-16 19:17:34.000000000 -0700
+++ 25-akpm/kernel/sys.c	2003-05-16 19:17:34.000000000 -0700
@@ -228,6 +228,8 @@ cond_syscall(sys_shutdown)
 cond_syscall(sys_sendmsg)
 cond_syscall(sys_recvmsg)
 cond_syscall(sys_socketcall)
+cond_syscall(sys_futex)
+cond_syscall(compat_sys_futex)
 
 static int set_one_prio(struct task_struct *p, int niceval, int error)
 {
diff -puN kernel/compat.c~CONFIG_FUTEX kernel/compat.c
--- 25/kernel/compat.c~CONFIG_FUTEX	2003-05-16 19:17:34.000000000 -0700
+++ 25-akpm/kernel/compat.c	2003-05-16 19:17:34.000000000 -0700
@@ -18,6 +18,7 @@
 #include <linux/signal.h>
 #include <linux/sched.h>	/* for MAX_SCHEDULE_TIMEOUT */
 #include <linux/futex.h>	/* for FUTEX_WAIT */
+#include <linux/unistd.h>
 
 #include <asm/uaccess.h>
 
@@ -211,8 +212,7 @@ asmlinkage long compat_sys_sigprocmask(i
 	return ret;
 }
 
-extern long do_futex(unsigned long, int, int, unsigned long);
-
+#ifdef CONFIG_FUTEX
 asmlinkage long compat_sys_futex(u32 *uaddr, int op, int val,
 		struct compat_timespec *utime)
 {
@@ -226,6 +226,7 @@ asmlinkage long compat_sys_futex(u32 *ua
 	}
 	return do_futex((unsigned long)uaddr, op, val, timeout);
 }
+#endif
 
 asmlinkage long sys_setrlimit(unsigned int resource, struct rlimit *rlim);
 
diff -puN include/linux/futex.h~CONFIG_FUTEX include/linux/futex.h
--- 25/include/linux/futex.h~CONFIG_FUTEX	2003-05-16 19:17:34.000000000 -0700
+++ 25-akpm/include/linux/futex.h	2003-05-16 19:17:34.000000000 -0700
@@ -8,4 +8,6 @@
 
 extern asmlinkage long sys_futex(u32 __user *uaddr, int op, int val, struct timespec __user *utime);
 
+long do_futex(unsigned long uaddr, int op, int val, unsigned long timeout);
+
 #endif

_

Re: [PATCH] 2.5.68 FUTEX support should be optional

[Werner Almesberger]

Alan Cox wrote:
> 	Remove kernel features for embedded systems (Y/N)

Add a comma ?

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/