RE: [PATCH] 2.5.68 FUTEX support should be optional

Linus Torvalds (torvalds@transmeta.com)
Wed, 14 May 2003 18:20:23 -0700 (PDT)


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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/