> > This model seems like a better fit for ptrace to me. The anchoring data > > structure is the tracer's tracees list, which links together the > > ptrace_context structs. A live ptrace_context has an engine pointer and > > a ref for it. > > OK. Not that I really understand this all in details, but OK. > > But. Do you think we should do this right now?
If it is the right way to handle the data structure lifetimes, I don't see why we would do it any different way first. One of the main points of what makes one plan or another "the right way" is that it makes it easier to get the corners right. So if it's easier to get the corners right another way, then maybe that other way is the right one. > I don't. Imho, we need a lot of changes before this. I don't understand why you think this. > We need the working code first. I just can't understand how can we do the > necessary changes to solve (say) the problems with de_thread() now, when > it is not clear (to me) how the basic/core ptrace code will look. This subject is part of how we organize the basic/core ptrace data structures. I don't think we have to make things like the MT exec case perfect right away. In fact, I think that wrinkle is the only thing that makes the "hold another ref" model I described not completely simple and straightforward to apply. > Do you have any suggestion what can we do right now? (assuming you won't > apply your ops->release patch). I didn't say I wouldn't. I was hoping for some more discussion about it and better understanding of the underlying issues that made you want it, maybe with some voices other than just yours and mine. I'm having trouble understanding why you think I've suggested some new tangent of work bigger or different from what you're already engaged in. So I'm at a bit of a loss for what different thing you're hoping I can suggest. > > I don't really follow this at all. > > Your ptrace code has nothing to do with utrace->lock, and never will. > > Yes, agreed. ptrace should not use utrace->lock. But currently I don't > see how to do this without utrace->lock. Or without rcu + refcnt. Sorry, but I still really have no idea what you are thinking about here. If you are considering overloading this unrelated lock for some purpose, you'll have to explain how you want to use it and why that's necessary. Thanks, Roland
