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    [from the cache]
©2003-2011 Jasper Spaans