[lkml]   [2003]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
    On Wed, 2003-10-01 at 11:11, Linus Torvalds wrote:
    > On Wed, 1 Oct 2003, Mikael Pettersson wrote:
    > >
    > > Linus' 2.6.0-test6 announcement doesn't seem to mention the
    > > fact that 2.6.0-test5-bk9 fundamentally changed the semantics
    > > of /proc/self and the /proc/<pid> name space.
    > Well, that's because the semantics weren't _supposed_ to change. The new
    > semantics were meant to be a superset of the old behaviour, with just the
    > added "task" subdirectory that lists the actual threads.
    > However, you're right that "/proc/self" should likely point into the
    > _thread_, and not into the task. But it's debatable. You are very likely
    > the only one who could ever care ;)

    That seems likely to break other stuff, as new-style
    threads become more common. Right now, many tools are
    unaware of new-style threads. Pointing at the tgid
    directory (POSIX PID directory) lets tools ignore threads.

    > > I don't actually disagree with the change, but it took me by
    > > surprise since neither the 2.6.0-test6 annoucement nor the
    > > diff between the t5-bk8 and t5-bk9 logs seem to mention it.
    > Well, the changelog mentions "fix for hidden task problem", since the diff
    > really is mainly to _add_ threads to the /proc layout. The fact that it
    > changed /proc/self is actually a bit surprising. Albert?

    This is an interesting problem for sure. The link was
    pointing to a directory that didn't get listed, except
    that CLONE_THREAD wasn't exactly a popular feature yet.
    So it was very seldom that the distinction mattered.

    Currently, I rely on checking for /proc/self/task to
    see if threads can be examined. Like this:

    task_dir_missing = stat("/proc/self/task", &sbuf);

    That wouldn't work if /proc/self pointed at the task.

    It certainly seems to me that the intent of /proc/self is
    to point to a "process", which is a tgid in kernel terms.
    Back in the 2.4.xx days, that was a pid in kernel terms.
    Now that we have CLONE_THREAD and the tgid, a "process"
    is represented by the tgid. Pointing to the tgid matches
    what other OSes do.

    I think there is something clearly defective about having
    the /proc/self link point to a hidden directory. It could
    be pointed at /proc/42/task/58 and such I guess, but I
    think tools could break as new-style threads begin to get
    used in the real world.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:49    [W:0.025 / U:51.184 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site