Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?

[Albert Cahalan <albert@users.sf.net>]

On Thu, 2003-10-02 at 00:58, Ulrich Drepper wrote:
> Albert Cahalan wrote:
> 
> > In that case, don't you already have a severe mess?
> > [...]
> 
> That's all completely up to whoever decides to use this combination of
> CLONE_* flags.  It might mean that SIGIO cannot be used and that fuser
> cannot be used.  But so what?  That might be acceptable in that
> situation.

To the user, maybe. To the admin, no. The admin uses
fuser and/or lsof to find out why he can't umount.
If those programs were thread-aware (they are not),
then they could take many minutes to run.

In other words, stuff runs faster if we can ban this.
If not, please suggest a way to make fuser and lsof fast.

> Of course it could be redefined as "point to the process group leader"
> but I'm not sure whether this and introducing "/proc/task" or so is
> worth the trouble.

Adding a /proc/task isn't any more trouble.
I guess I'll do that in any case.

If /proc/self should be some deprecated hack that
goes through the invisible non-leader directories
at top-level, then it itself should be made invisible
and a /proc/proc (pointing to tgid) should be added.
A /proc/proc could be backported to 2.4.xx. We'd then
have top-level links for process (tgid, "proc", POSIX PID),
thread (pid, "task", POSIX TID), and... an ugly thing
that we can kill 5 years from now.