> There is at least one change from the earlier behaviour -- rather than > utrace_attach_task() retrying by itself on a !parent attach, -EAGAIN is > returned to the user. That may need changes to the utrace client side.
Oops, that was not intentional. I've restored the old behavior. > I've just started with implementing a non-disruptive application core > dump. Its probably too early to commit, but it could also be a potential > in-kernel user of utrace. I've just started with quiescing all threads > but need to plug-in the core generating infrastructure for it. I am looking at > the possibility of tweaking do_coredump() to reuse it for this while the > workhorse can just be the binfmt->core_dump() itself. Its still in the > early prototype stage -- I'll post that when there is something more > concrete. Ideas/suggestions welcome! Oh yeah. I almost started on one of those a while back, and I have certainly put a lot of thought into the subject that we can discuss later. It is a bit of a can of worms in that the right long-run way to approach it will involve a bunch of refactoring. (That's why I haven't suggested it as a quick, clean, and self-contained demo of things utrace can do, like Frank's ftrace widget patch is. I also just hadn't thought about it in a while.) Please start a proper thread about that. Thanks, Roland
