> Yes, I believe that is Roland's intent. I believe it was separated > from the current suite of patches for staging purposes, to merge the > most solid code up first. The code is available from the utrace git > tree in the utrace-ptrace branch.
More than just "staging". The utrace-ptrace code there today is really not very nice to look at, and it's not ready for prime time. As has been mentioned, it is a "pure clean-up exercise". As such, it's not the top priority. It also didn't seem to me like much of an argument for merging utrace: "Look, more code and now it still does the same thing!" Instead, I figured we should merge utrace in a way that lets everybody beat on it for new features and hash out details, without immediate risk of regressions in ptrace (which are severely annoying to everyone when they happen). The proper clean-ups for ptrace can proceed in parallel with work using utrace for things that are actually new and interesting, and at least the first half of that clean-up work is orthogonal to utrace. This seems like the normal way that new optional CONFIG_FOOBAR features (marked EXPERIMENTAL, even) are handled. We don't jump over ourselves to make existing crucial code paths subject to a new subsystem that is getting its first rounds of shake-out. Thanks, Roland