![]() | |||||||||||
Messages in this thread |
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-2008 | |||||||||||