Phil Muldoon wrote:
Chris Moller wrote:Due to a complete lack of interest, I'm shelving utracer. May it collect dust in peace.I was (and still am) interested in it from a direct api point of view. As a an end-tool not so much.Systemtap is cool, and, based on tinkering with it for a while, is great for finding deep, hairy, stuff, but doesn't appear to lend itself to highly interactive use in debuggers.When you mean a Systemtap like approach, what do you mean? I am doing poor service in describing Systemtap, but do you mean compiling a script/api into a utracer kernel module and aggregating data from that? If this were the approach would not an assembly of scripts be the debugger itself?
I'm certainly no systemtap expert, but at least one limiting factor I see is that compiling and loading a kernel module takes time and resources way beyond the trivial--I can't imagine such an approach being workable in an interactive environment. You almost certainly couldn't do it an a per-user-interaction basis with anything like decent response time.
The whole-new-syscall thing, at which I started some tentative hacking a while ago, was based on my aversion to hacking into Other People's Code, mostly kernel/ptrace.c in this case--I just thought it more expedient to be as unobtrusive as possible. At least one downside of this, of course, is the redundancy with ptrace. (And I suspect it might be difficult to coordinate getting a new syscall number universally accepted upstream, but I don't have much of a clue about that.)I am not sure how this would scale. It would be cool to see how it did in a basic prototype, if only to rule it out due to performance and scalability.
I'm not sure what you ean by "scale." My sandbox code added one new entry in unistd.h: __NR_utrace, 327, The redundancy I'm talking about is that ptrace() capabilities, stepping, peeking, poking, etc., would continue to exist in ptrace (in kernel/ptrace.c), but would be replicated as a subset of the capabilities of utrace() (actually, syscall(SYS_utrace,...) until libc caught up) in a hypothetical kernel/utrace_ui.c (Not so hypothetical, actually--that's what I called it.)
That leaves, unless someone has a better idea, extending ptrace. I started a bit of tentative hacking on that yesterday. Turns out, actually, that it was easy to do that minimally intrusively. (It's about a ten-line patch to kernel/ptrace.c to add a default case to the ptrace_common() request switch that calls an external fcn to decode extensions to the PTRACE_* requests., plus a patch to include/linux/ptrace.h to add the new request number #defines. All the real hacking is in the external fcn.) At least one upside of this, of course, is that there's no redundancy with ptrace.I've no opinion on this, and it always tends to generate debate on why ptrace works, does not work, ptrace rules, ptrace sucks type arguments. I'm curious to why you think this approach is relevant/useful though? Is it from a maintainability viewpoint? Performance?
Several things: extensions of ptrace can do arbitrary things completely unlike the capabilities of existing ptrace()--there'd be an an entire new range of requests extending the usual PTRACE_POKE*, PTRACE_PEEK*, etc., stuff to include, hypothetically, things like UTRACE_WAIT. (Again, not so hypothetical: I've already sandboxed that: it acts like a super, highly controllable, waitpid(), that unblocks on a call-defined subset of task state changes, signals, syscall entries/exits, etc.) It certainly is more maintainable than replicating ptrace() capability in a comprehensive utrace(), and, either as an extension of the ptrace syscall or as its own utrace syscall, it's got a lot better performance than the /proc entry approach--thee's a lot more overhead associated with read(), write(), and ioctl() than with a direct syscall.
Thanks Phil
--
Chris Moller
I know that you believe you understand what you think I said, but
I'm not sure you realize that what you heard is not what I meant.
-- Robert McCloskey
signature.asc
Description: OpenPGP digital signature
