Messages in this thread | | | Date | Wed, 3 Sep 2008 14:41:27 -0400 | From | Christoph Hellwig <> | Subject | Re: [PATCH 2/2] utrace: ptrace cooperation |
| |
On Wed, Sep 03, 2008 at 05:10:11AM -0700, Roland McGrath wrote: > > I don't like this patch in it's current form. Having two different ways > > to do ptrace is a rather awkward thing and not very good for testing > > coverage. This should not be an option but required. > > The main idea behind having CONFIG_UTRACE_PTRACE be an option separate > from CONFIG_UTRACE is just for debugging during this development and > transition period. With CONFIG_UTRACE=y, CONFIG_UTRACE_PTRACE=n, then > ptrace works as it ever did. You'll only have trouble if you use utrace > on the same tasks. So if you hit bad problems working on something > using utrace, you can always switch to CONFIG_UTRACE_PTRACE=n to use gdb > and strace et al reliably on your userland code, which might be damn > helpful in figuring out how you're triggering the utrace bugs. By the > time it's no longer EXPERIMENTAL, the separate option could be gone.
No problems doing it in your tree, but it's not how features get into mainline. Transition periods like this are bad, because people will simply disable the option if it doesn't work, and it will never get debugged. Conditional implementation of core functionality are the worst case for code coverage.
> don't care. An arch deadline is fine with me (I'm not the one who has > to meet it). I've always assumed there would be one eventually. But > any reasonable deadline would be some time hence, I don't know how long > (time scales in feature-removal-schedule.txt seem to be pretty long). I
At least one or two major release. So in your place I would try to get consensus on linux-arch _now_. I've also tried to poke multiple arch maintainers into updating their implementations for other reasons in private, and the feedback has generally been postive.
> Some more ptrace cleanups can be done orthogonal to utrace, > e.g. reorganizing the data structures as you mentioned in another > message. This can be done in parallel to getting utrace in shape. > Doing it that way makes it easy to test and prove those cleanups on > their own and thus isolate any ptrace regressions either to those > changes or to utrace problems.
I don't think moving ptrace data insto the engine state is a minor reoraniation. It's shoveling free some space that you need for utrace itself if we want to get rid of the nasty dynamic allocation of it, which I really really think we want.
| |