On Nov 27, 2007 7:49 PM, Guillaume Chazarain <[email protected]> wrote:
> [email protected] wrote:
>
> > We may be stuck with the current broken behavior for backwards
> > compatibility reasons but lets try fixing our ancient bug for the 2.6.25
> > time frame and see if anyone screams.
It's not broken. It's just not the feature you're looking for.
> I'm not screaming because of this change, but I screamed when I
> discovered I could not have a replacement for gettid() in Java, or any
> other high level environment.
Java is so high-level that it seems inappropriate to touch /proc.
It is allowed for Java to do N:M threading you know.
> So, instead of making /proc/self an unstable interface that changed in
> 2.6.0 and 2.6.25, I'll vote for /proc/self/task/self. A new interface
> that can trivially be detected for existence, and programs relying on
> this interface will loudly break on older kernels, unlike with the
> proposed interface change.
>
> Ccing Albert Cahalan as he made the change to /proc/self in the first
> place:
Changing /proc/self is somewhat risky, and probably
undesirable anyway. That file has always been used
to represent the process; at one time this also meant
the task. Documentation everywhere says "process".
This one is probably best:
/proc/task -> 123/task/456
(with both numbers showing)
The problem with /proc/self/task/self is that it
makes /proc/789/task/self be ill-defined when
the observer is not tgid 789. If the directory can
only show up in the observer's own task directory,
then this solution is good.
I really don't want to see anything that would encourage
more use of the gdb backdoor. For those that don't
remember, gdb broke when access to threads via the
top-level /proc directory was temporarily removed.
We need that back door, unfortunately, but having it
show up in symlink targets is quite nasty.
As for the history:
I left it out. At the time it would have been fairly useless.
Back then, glibc didn't make things painful by pulling
phony thread IDs out of its ass. Shell scripts sure didn't
deal in threads. Monitoring tools like "ps" didn't need it.
If nothing needs it, well, why have it?
Regarding some of the discusison on LKML, I don't see
how unshare matters. If you unshare to the point where
you get a new TGID, then /proc/self must reflect that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
