Sorry for the delay. I was travelling last week. > When I tried to do a make "allmodconfig" or make "allyesconfig" > from utrace kernel tree cloned from > git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-utrace.git
Sorry, I left the old branches there though they are quite stale now. I've fixed that repo to point its HEAD and master at the current branches. > Also you had sent a mail about the new utrace branch in the > linux-2.6-utrace.git repo. Is it stable enough to start testing and > making changes based on it? Or do we still need to use the master branch > of the same repo. > > If we still need to use the master branch, when can we expect the next update > to this branch? The new code is certainly not stable yet, but it is the only game in town. (That is, it's the only fork I'm going to maintain.) If you are doing pure utrace-based hacking, you can play with the current code if you are adventurous. I expect you will find some problems. The state of the new utrace code is that it has passed some nominal testing (only tried on x86_64) but not really been shaken out much at all yet. There is no integration with ptrace in the code currently in GIT. I'm working on that now. For now, don't use ptrace and utrace on the same thread and you should not have any trouble with ptrace, but if you do, all bets are off. The ptrace integration work I'm doing now is shaking out some bugs in the new utrace code. When that's limping along, I'll put it onto the same GIT branch (the one called "utrace"). There are some known loose ends in the new utrace code that I plan to cover after the basic stuff is stabler. In particular, the picture for single-step and for signal handling is still a bit fuzzy. So don't be surprised to see holes there, but all feedback is welcome. Thanks, Roland
