On Sun, 17 Nov 2002, Ingo Molnar wrote:
>
> the problem is the following: the 'initial thread', ie. the 'process',
> does not have any ->user_tid value set. But still it's a generic thread
> that can be pthread_join()-ed upon. (but pthread_join() does not work, the
> kernel does not do the futex wakeup because ->user_tid is NULL.)
There is no way in _hell_ that the correct way to handle this is by doing
magic things at execve() time. Stop that NOW!
First off, a program had better be correctly startable even if the
process that does the execve() is _not_ using the new glibc. If I have an
old "bash" binary, and that means that I cannot start up new binaries
correctly, that is BROKEN. It's so incredibly broken that it's scary.
Why not do it the _sane_ way, with a system call in crt0.S instead to set
up the user_tid if you want it?
This patch is crap, or at least needs a ton more explanation about why you
would do something that looks quite this horrible and stupid.
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/
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:19 EST