> I think you misunderstood my point. I never advocated the wholesale, > unconditional rewriting of ptrace. A gradual approach there seems a > must - and your approach of CONFIG_UTRACE_PTRACE seems like the way > to go, initially.
Ok, good. I was confused by your focus on the diffstat and your apparent expectation that these changes should make all ptrace source files smaller. Thanks for clearing that up. I will note again here that a bunch of ptrace clean-ups I anticipate will be purely in reorganizing its own data structures independent of the utrace issue. Those will be incremental changes in many bisectable baby steps, but they won't be conditional. > What i tried to get at is the "how will the end result look like" > qestion - because arguably a ptrace replacement will be the end > goal. Right. > ( Note, Linus might still insist on a total replacement, if he > finds the #ifdef approach too ugly. I dont talk for him and he is > usually much pickier than me. ) In a previous round of review, hch objected to CONFIG_UTRACE_PTRACE. I think we are all in agreement that the eventual right place will be only one ptrace implementation, and that being the one based on a clean framework. It's not very clear to me which different incremental paths to get there different people have in mind or why. Everyone agrees #ifdef for two implementations is ugly. It's a transitional stage, so to me it seems quite tolerable knowing that it will be cleaned up eventually. It buys two things: 1. getting utrace in sooner, worked on faster, and made better soon; 2. given that, risk mitigation for everyone not interested in working with utrace. Thanks, Roland
