LinuxLists.cc - [PATCH] 2.5.68 FUTEX support should be optional

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

Christoph Hellwig <[email protected]> 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

_

2003-05-14 06:22:56

by Christoph Hellwig

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

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.

2003-05-14 07:39:38

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

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)
{

2003-05-14 19:07:24

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

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

2003-05-14 19:19:06

by Dave Jones

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

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

2003-05-14 19:32:32

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

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

2003-05-14 19:37:45

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

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

2003-05-14 19:53:07

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

Linus Torvalds <[email protected]> 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.

2003-05-14 20:32:00

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

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

2003-05-14 20:41:46

by H. Peter Anvin

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

Followup to: <[email protected]>
By author: Davide Libenzi <[email protected]>
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
--
<[email protected]> at work, <[email protected]> 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

2003-05-14 20:53:19

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

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

> Followup to: <[email protected]>
> By author: Davide Libenzi <[email protected]>
> 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

2003-05-14 22:17:26

by Chuck Ebbert

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

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)

:)

2003-05-14 22:47:13

by Carl-Daniel Hailfinger

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

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.

2003-05-14 23:20:35

by Perez-Gonzalez, Inaky

[permalink] [raw]

Subject: RE: [PATCH] 2.5.68 FUTEX support should be optional

> From: Christopher Hoover [mailto:[email protected]]
>
> 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)

2003-05-15 00:33:45

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

"Perez-Gonzalez, Inaky" <[email protected]> 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.)

2003-05-15 00:39:22

[permalink] [raw]

Subject: RE: [PATCH] 2.5.68 FUTEX support should be optional

> "Perez-Gonzalez, Inaky" <[email protected]> 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

2003-05-15 00:45:34

[permalink] [raw]

Subject: RE: [PATCH] 2.5.68 FUTEX support should be optional

> 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

2003-05-15 00:48:04

[permalink] [raw]

Subject: RE: [PATCH] 2.5.68 FUTEX support should be optional

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

2003-05-15 01:08:02

[permalink] [raw]

Subject: RE: [PATCH] 2.5.68 FUTEX support should be optional

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

2003-05-15 01:16:26

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

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

2003-05-15 01:11:18

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

Linus Torvalds <[email protected]> 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.

2003-05-15 01:25:17

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

Linus Torvalds <[email protected]> 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"

2003-05-15 01:31:06

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

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

2003-05-15 01:49:58

[permalink] [raw]

Subject: RE: [PATCH] 2.5.68 FUTEX support should be optional

> 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

2003-05-15 02:06:25

[permalink] [raw]

Subject: RE: [PATCH] 2.5.68 FUTEX support should be optional

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

2003-05-15 02:09:45

by Miles Bader

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

Linus Torvalds <[email protected]> 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_)

2003-05-15 02:47:44

by Arnaldo Carvalho de Melo

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

Em Wed, May 14, 2003 at 06:39:25PM -0700, Andrew Morton escreveu:
> Linus Torvalds <[email protected]> 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

2003-05-15 03:35:33

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

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

2003-05-15 16:46:25

by Ingo Oeser

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

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

2003-05-15 16:53:31

[permalink] [raw]

Subject: RE: [PATCH] 2.5.68 FUTEX support should be optional

> 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

2003-05-15 17:33:56

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

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

2003-05-15 17:54:41

by Bill Davidsen

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-05-15 18:03:49

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

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

2003-05-15 18:07:27

by Bill Davidsen

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

On Wed, 14 May 2003, Andrew Morton wrote:

> Linus Torvalds <[email protected]> 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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

2003-05-16 22:41:43

by Alan

[permalink] [raw]

Subject: RE: [PATCH] 2.5.68 FUTEX support should be optional

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

2003-05-16 23:48:12

by Valdis Klētnieks

[permalink] [raw]

Subject: Re: [PATCH] 2.5.68 FUTEX support should be optional

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

Attachments:

(No filename) (226.00 B)

2003-05-17 02:22:21