Phil Muldoon wrote:
Chris Moller wrote:Phil Muldoon wrote:Thanks for the description Chris. From an ntrace client implementation "point of view", non-ordered replies to asynchronous requests present an ordering conundrum in the client - especially as it scales to many many inferiors.I tend to think of the asynch stuff not as "replies" but as "responses," of which there are three types. The most common (this is from utracer--things may change) is the response to an operational change like a "quiesce" command. The command itself is non-blocking and returns immediately to the caller, and the kernel action is immediate--setting the QUIESCE bit in the utrace engine--but the task won't actually quiesce until it's in, to use Roland's description, a "safe" state. At that point the engine issues a report_quiesce() which results in an asynchronous response, on the response thread, to the debugger.Sounds sensible. Perhaps from the old utracer, or this new interface, do you have a running api?
The original utracer API header is in utracer/utracer/include/utracer.h (from the CVS repo cvs -d :ext:cvs.ges.redhat.com:/cvs/cvsfiles co utracer) and the docs are in utracer/docs. ("make pdf", "make html", and "make txt" make more readable PDF, unified HTML, and text files respectively. Just "make" makes man pages.)
It doesn't have to be finished, or even set in stone.
It's mostly complete--some stuff I never got around to documenting, but you'll get the idea. The one thing you'll note, however, is there's not much in the way of reference to actual protocol to and from the module in the docs. That's because I spent the last six months or so of active work on utracer hiding all that messy stuff from Java, which is clueless about C stuff like unions of structs, which is what the module protocol was based on. You can get that from the utracer.h headers and utracer/utracer/utracer.c where the actual ioctl()s are. (Turns out I wasn't following the conventions on the use of ioctl in utracer--my new boilerplate is doing it right.)
Just an idea. I'm guessing your answer will be, look in the code when I get the repository up ;) But it would be interesting to see this in the making. The Quiesce command above for example. I'm pondering what happens if a task dies before it reached a safe state to be quiesced.
That's more a utrace internals question that Roland can handle better than I can, but the off-the-cuff answer would be that the engine would generate something like a report_signal(), report_exit(), or report_death() , depending on the manner of death, instead of the report_quiesce() and that would result in an asynch response to the app.
Over on Frysk we are taking a good, long look at our goals and one of those is interfacing to the new user-land api of utrace. Is there a moral equivalent available yet to the ptrace like control enums that one used to use with ptrace?
Not for the real thing, but near the top of utracer.h is a list of IF_CMD_* enums utracer supported. Further down is a list of IF_RESP_* enums detailing the possible response types.
A second kind of response is less direct. For example, the debugger can issue a command to report the arrival of specified signals or entry into (or exit from, or both) specified syscalls. Again, the response to the command is non-blocking, but there obviously won't be a response-thread response unless and until that a qualifying signal arrives or a qualifying syscall is actually entered or exited.Finally, there are truly immediate responses. For example, a request for the contents of one or more registers (utracer allowed the app to request a range of regs, e.g., all the GPRs, down to and including a single specified reg) will be responded to immediately, on the control thread, with that information. (Assuming the task is quiesced; an error condition will be raised otherwise.)I'm not sure I hold truck with responses appearing on a control thread and the response thread. It would require a bit of knowledge beyond the api (I'm calling the interface an api, for want of a better term). What's preventing scheduling a reply to an immediate response on the response thread over the control thread?
Immediate responses are generally done by way of a pointer passed through the ioctl() and into which the module copies the appropriate data. Register reads, for example, do this. The actual response from the ioctl is just a success/fail return value that sets errno. Nothing says, though, that even for immediately available data like register values there can't be both synch and asynch versions of the request.
All response-thread responses are structured and contain an enum specifying the nature of the response--"here's a syscall entry of the kind you asked for"--as well as the PID of the task that generated the response. If it would be useful, I suppose some sort of sequence number could be returned as well, or maybe an application-supplied transaction identification number could be returned. That might help in dealing with out-of-order problems.When the the code is up somewhere, and we look at the api, we could revist this a bit later perhaps.Regards 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
