On Thu, Oct 7, 2010 at 8:34 PM, Lluís <xscr...@gmx.net> wrote: > Blue Swirl writes: > >> The patches there seem to be fixes or small changes to your other >> patches. This makes any review very difficult. > > Sorry, I'm really new to git, so I don't really know how to maintain and > "grow" an organized set of patches for review while I keep improving the > work.
Some kind of patch queue or stack tool can help, I use StGit (integrates nicely with QGit) but there are others. The workflow should aim for a set of committable patches. This means that instead of patch sequence 1 - implement feature A 2 - fix for feature A 3 - implement feature B 4 - more fixes for feature A 5 - fixes for feature B etc, the patches should be perfected, like this: 1 - implement feature A 2 - implement feature B This can be achieved by working with the patch stack: 1 - implement feature A fix for feature A needed: fix, refresh 1 2 - implement feature B more fixes for feature A needed: pop 2, include fixes to 1 fixes for feature B: push 2, fix and refresh 2 This also makes keeping up with HEAD simpler (though conflicts need to be managed anyway): pop all patches git pull push patches one at a time, fix conflicts if needed. >> But I'm not sure the architecture is what we'd like to see integrated >> in QEMU, though I may have missed the whole picture because of the >> patch fragmentation problem. Before doing any work to possibly go >> further in wrong direction, please try to submit early some preview >> version for comments and review. > > I can try to refactor the changes into a sensible set of patches, but > please read first the motivation of this work (below). > > >> Just as an example, perhaps the existing tracing framework could be >> extended to cover also your needs. > > Well, for what I've seen of the tracing infrastructure ("tracing" from > here on), it is geared towards tracing qemu internal events (for > analyzing qemu performance), while static instrumentation > ("instrumentation" from here on) is geared towards tracing guest events, > in order to analyze guest behaviour. > > The reason for having static instrumentation points in the form of > macros (diverging from the approach taken in tracing) is that the most > common instrumentation points are invoked at code generation time. This > way the user can dynamically select which extra code to call and/or > generate (if any) on each of these points, with the addition that code > can be selected for regeneration when the instrumentation points need to > produce different code (e.g., no instrumentation, event counting, > sketchy trace generation, detailed trace generation, etc.). > > So, I think they are geared towards different goals, although they are > indeed composable (e.g., the user can expand the instrumentation macros > into calls to the tracing infrastructure). Maybe the goals are different, but even with this description, I don't see why tracing could not be extended also to generated code (again, I don't know the instrumentation side). From QEMU code maintenance point of view, a unified approach would be much preferable to two different, overlapping systems. > Wether or not this fits into upstream qemu is not for me to say, but it > provides the initial stepping stone that is commonly used in computer > architecture research (e.g., http://www.ptlsim.org or > http://sesc.sourceforge.net/), with the added bonus that qemu supports > multiple ISAs, as well as executing standalone applications and a > full-fledged system. > > Of course, the simulator itself would be out of qemu, thus the macros :) Is the simulator available? Otherwise testing would be difficult.