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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
