Re: + proc-fix-the-threaded-proc-self.patch added to -mm tree

[Ingo Molnar]

* Albert Cahalan <acahalan@xxxxxxxxx> wrote:

> On Nov 27, 2007 7:49 PM, Guillaume Chazarain <guichaz@xxxxxxxx> wrote:
> > akpm@xxxxxxxxxxxxxxxxxxxx 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.

well it's quite broken at the moment and we are looking for solutions 
not for a blame game :-) You might have read the thread where i describe 
what i had to go through to do something fairly trivial.

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

in Linux we never truly had a notion of "process" when your change was 
done - "process" always meant the task itself. That's why all the 
task_struct parameters/variables used to be named 'p', not 't'. So when 
NTPL came around this became a poorly defined notion.

> This one is probably best:
> /proc/task -> 123/task/456
> (with both numbers showing)

this sounds good to me. If it's a symlink then there's not much other 
choice because the thread PIDs do not even show up under /proc anymore.

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

agreed.

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

sound, future-proof API design, with a little bit of foresight? I am 
faced with incidents on an almost daily basis that show how much we 
kernel folks suck at defining new APIs. The only luck is that the set of 
system calls is fairly complete already - but in the rare case where we 
touch an API it's a catastrophy most of the time. With such an API track 
record we'd probably never survive as a user-space project.

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