> Count me, and most/all of the SystemTap team, among the folks who would > like to see utrace accepted into Linus's kernel. Upstream acceptance > seems to be bogged down on the following points: > 1) On some architectures, ptrace still hasn't been successfully adapted > to use utrace.
The arch issue has been something of a red herring. It's really easy enough to do the arch work that it wouldn't have been a big deal on that front if the code had just gone in and every arch maintainer had to spend a day making it work again. But, it has been manifestly true that most arch maintainers have not been motivated to consider the whole subject (and that one or two have gotten confused, thought there was more work required than there really is, and may have become actively disinterested). > 2) The current utrace patch set may be too big a mouthful for the kernel > community to digest all at once. That is true, though in reality there is no real consistent "bite size" and huge new things do go in barely examined when noone bothers to make a stink. But whatever, I am not the lucky sort. There are also bona fide concerns with the core implementation details of utrace (the kernel/utrace.c code), likely to impinge on the interface around the margins (locking and data structure lifetime management stuff). But noone has really engaged in a meaningful discussion about that or a deep review of the code. I think the the arch question and the overall "too much to swallow" have been easy to just throw up as roadblocks and so avoid getting to the meaningful stuff that requires real thought to review. > This suggests an incremental approach to pushing utrace upstream. I agree. Please note that the original approach was intended to be layered and incremental from the start, in the sense that the tracehook and regset patches could go in without committing to any particular design or interface decisions for utrace (or even having anything by that name). But it's not fully incremental in the sense that it breaks ptrace to remove it cleanly before adding it back. And as things have turned out, this has been a big obstacle. Lately I have been thinking about a different ordering/slicing of the work that in today's circumstances I believe has a better chance of getting some incremental progress on integrating the code. The first stage of the plan is basically to merge all the arch code first. This is sort of already the way the patch series works, utrace-regset is before utrace-core. The new plan is to do all that in an incremental way that does not perturb the generic ptrace code much and can go in as an independently motivated cleanup without delay. I'll post here momentarily on the detailed steps of the work to be done. Thanks, Roland
