lkml.org 
[lkml]   [2005]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC] [PATCH 00/13] Introduce task_pid api
    From
    Date
    On Wed, 2005-12-07 at 12:19 -0700, Eric W. Biederman wrote:
    > Process groups are also pids, and there are direct relationships
    > between pids and process group ids and session ids. I agree keeping
    > the focus tight make sense but not so tight that you miss pieces.

    There's a "reference implementation" that the kernel community hasn't
    seen which is certainly not mergeable, but shows all of the pieces.
    Personally, I really want to share it, and I hope that we can soon.

    > >> At the current time the patch definitely fails the no in kernel
    > >> users test because it doesn't go as far as taking advantage
    > >> of the abstraction it attempts to introduce. Which means
    > >> other people can't read through the code and make sense
    > >> of what you are trying to do or to see if there is a better way.
    > >
    > > This isn't excatly a new feature, nor does it add any appreciable code
    > > or complexity. I'm not sure that test even applies.
    >
    > A very common comment on the thread up to now is that people haven't
    > seen the big picture so they can't comment.

    Yup, this is a big issue. I think getting that "other code" out there
    is part of filling you guys in. The other part is discussions like
    this. :)

    >From your comments, I can see that you have a much bigger piece of the
    picture in your head than you think.

    > >> Another question is how do your pid spaces nest.
    > >
    > > They don't, and thankfully there is anybody asking for it. It adds
    > > loads of complexity, and nobody apparently needs it.
    >
    > So only very special pids can generate a pidspace. That will
    > tend to reduce the generality of the solution. What do you do
    > if I am running your code in a vserver?

    I don't think it would be a good idea to stack these containers within
    vservers, either. vserver uses different pidspaces, and will use the
    same infrastructure. The only difference is that they only have a very
    small change to the different pidspaces for init.

    > >> Who do you report as the source of your signal.
    > >
    > > I've never dealt with signal enough from userspace to give you a good
    > > answer. Can you explain the mechanics of how you would go about doing
    > > this?
    >
    > Look at siginfo_t si_pid....

    Are those things that are exported outside of the kernel? It's not
    immediately obvious.

    > >> While something allowing multiple pidspaces may be mergeable,
    > >> unnecessary and incomplete changes rarely are. This is a fundamental
    > >> change to the unix API so it will take a lot of scrutiny to get
    > >> merged.
    > >
    > > Lots of good questions. I think we need to take some of our initial,
    > > private discussions and get them out on an open list somewhere. Any
    > > suggestions? I hate creating new sourceforge projects :)
    >
    > I wonder if you could hook up with the linux vserver project. The
    > requirements are strongly similar, and making a solution that
    > would work for everyone has a better chance of getting in.

    Already hooked up. They need the same stuff we want, just in smaller
    quantities. They can easily stack on top of whatever we do.

    -- Dave

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

    \
     
     \ /
      Last update: 2005-12-07 22:43    [W:0.036 / U:90.820 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site