Jump to: navigation, search

Difference between revisions of "DSDP/DD/DebugModel"

< DSDP‎ | DD
(Requirements discussion)
(Requirements discussion)
Line 8: Line 8:
  
 
===Introduction===
 
===Introduction===
I really don't know how it's possible to start a requirements discussion without having a specific problem or use case to be solvedWhat generally happens in these situations, is that a set of adjectives are listed that are so un-specific that they are impossible to take an action upton: "scalable", "flexible", "responsive", etc.  On the other extreme, if everyone comes to the table and describes their specific problem that they are trying to solve, the discussion tends to drift towards completely irrelevant topics and often goes to try to solve conflicting problems that aren't even in the scope of the original architecture.
+
OK, I guess I got over-ambitions with the literary analogyFor sake of time I'll stick to just listing out the requirements.
  
So I propose a third approach to this discussion, which I think might be a lot more fun than describing intricate details of everyone's debugger. Let's define a completely theoretical debugger problem, one that we can use to represent all of the different types of problems that we have to solve for our very different debuggers.  We don't necessarily have to try to roll all of our different and sometimes divergent problems into one theoretical model, we could have many different versions of the model, and then try to apply our solution to fit these different needs.  As we introduce features into this model, we could tie these into specific requirements that we already have defined for our products.  Hopefully this will be a lot more fun than a traditional technical discussion. 
+
===Scalability===
  
===Citizen monitoring system in George Orwell's 1984===
+
* ''There should be no assumptions about the number of objects that the debugger might need to track.''
For those unfamiliar with the book, in 1984 the citizens of Oceania live under the constant watchful eye of the Party and its leader Big Brother. The Party has mandated that all citizens have a ''telescreen'' installed in their private homes, as well as in all public spaces in Oceania.  The telescreens are both a camera through which a party official could be looking, and a display monitor through which messages could be sent to the individual citizen.   
+
* ''The debugger views need to be able to rely on the external debugger process to perform filtering and sorting of the data to be presented to the user''.   
  
Designing the monitoring system was a formidable task, Oceania is a huge nation of hundreds of milions of citizens, and only 15% of this population are members of the Party, and of those 15%, only a small fraction are in the Inner Party who are trusted enough to be monitoring citizens and other Party members.  So most of the work of the monitoring system falls onto the automated monitoring system, based on the latest microprocessor designs no doubt, which looks at everyone through all telescreens all the time and watches for signs of ''thoughtcrime''.
+
===Connectivity between debugger and target===
 
+
===Debugger for the citizen monitoring system===
+
We would like to design a debugger which will help us debug the telescreen monitoring system within our Eclipse-based debugger.  And based on the information so far, we can already draw up some requirements that our debug model will have to meet:
+
 
+
* ''There should be no assumptions about the number of objects that the debugger might need to track.''  In Oceania, there are hundreds of millions of citizens and there are just as many telescreens.
+
* ''The debugger views need to be able to rely on the external debugger process to perform filtering and sorting of the data to be presented to the user''.  There is a powerful database computer somewhere deep within the headquaters of Thought Police, that performs the tasks of sorting, filtering lists of citizens, there is no way that a simple PC could store this much information, much less to process all of it.
+
 
+
===Connectivity between debugger and monitoring system===
+
We know for certain that the citizen monitoring system is an extremely distributed system; there are hundreds of millions of monitoring screens, which are connected to hubs which are then connected to the central monitoring computer.  But as far as how the debugger is connected to the system we are starting to have a few options:
+
# We may have the priviledge to actually install Eclipse on the central monitoring computer and be able to debug the system on the local host.
+
# More likely we will not have the priviledge to sit at the precious central monitoring computer that is running deep within the headquaters of the Thought Police.  Instead we will have to be at some remote computer connected over ethernet of DSL, or maybe dial-up, and our debugger will be communicating to an agent application that is running on the central monitoring computer which is directly controlling and inspecting the monitoring system.
+
# Another possibility is that the debugger will have to communicate both with the central monitoring computer and the multiple hubs or even to the individual telescreens to retrieve specific detailed data from the system.
+
 
+
Given these different possibilities, the corresponding debug model requirements are as follows:
+
 
* ''Debug model implementation should be able to communicate with a back end over a slow connection with a large latency.''  
 
* ''Debug model implementation should be able to communicate with a back end over a slow connection with a large latency.''  
 
* But for local host debugging, ''It should also be able to communicate over a very fast connection without loss of efficiency''.
 
* But for local host debugging, ''It should also be able to communicate over a very fast connection without loss of efficiency''.
Line 36: Line 22:
  
 
===What debug data should be presented and where===
 
===What debug data should be presented and where===
 +
IMO this is the biggest challange for the debug model implementation, simply because different embedded debuggers can have very different visual representations.
 +
* ''Debug model should allow arbitrary layouts of nodes representing debugger entities.''
 +
* ''Ideally, debug views should allow the user to reconfigure the content and layout of various debug views to suit individual preferences.''  This seems like a strech, but the reality is that many of our users migrate from using very specialized debuggers which may have an unorthodox ways of presenting data.  For such users it would be best to allow them to customize their views to match their working style.
  
 +
===Interoperability with 3rd party tools and standard clients===
 +
Even though many aspects of embedded debugging is unique to a given vendor/target configuration, etc, all of these debuggers share some common functionality found in standard debuggers (reading/writing memory, run control, stack retrieval, expression evaluation, etc). 
 +
* ''Debug model should define a set of public APIs to access common debugger functionality, either by supporting existing APIs (Platform, CDI, JDI) or defining new ones.''
 +
* ''If new APIs are defined, the model should have the ability to support legacy APIs: Platform, CDI, etc.''
  
 
===Update policies for debug data===
 
===Update policies for debug data===
 +
Because of the lazy loading nature of the views, update policy has to be implemented by the model, and cannot be solved at the view level.  Pushing this problem down to the model level doesn't solve all the issues, because the model itself will likely need to use lazy loading when retrieving data from a slow target, but at least it will allow for consistent information to be shown in the various views that are looking at the same data.
 +
* ''Debug model should provide a standard API for configurable update policies including auto update, manual update, and timed update.''
  
 
===Filtering and sorting of debug data===
 
===Filtering and sorting of debug data===
 
+
This is another problem that cannot be solved at the view level because of lazy loading.  And even at the model level, many of the models may not be able to implement sorting or filtering because they may be limited by the capabilities of the target or out of process/JNI debugger back end.
===Interoperability with other debuggers===
+
* ''Debug model should provide a standard API for sorting and filtering options.

Revision as of 14:06, 8 June 2006

This is the Debug Model Sub-group

Lead: Pawel Piech (Wind River)
Members: Mikhail Khodjaiants (QNX), Freescale, Nokia



Requirements discussion

Introduction

OK, I guess I got over-ambitions with the literary analogy. For sake of time I'll stick to just listing out the requirements.

Scalability

  • There should be no assumptions about the number of objects that the debugger might need to track.
  • The debugger views need to be able to rely on the external debugger process to perform filtering and sorting of the data to be presented to the user.

Connectivity between debugger and target

  • Debug model implementation should be able to communicate with a back end over a slow connection with a large latency.
  • But for local host debugging, It should also be able to communicate over a very fast connection without loss of efficiency.
  • There should be no assumption that there is only a single connection to the back end, because the debugger itself might be distrubted in a distributed system.
  • It should be able to communicate over a very un-reliable connection, where the connection might be lost, then later recovered, and the debug model should be able to re-synchronize itself with current state of data on the debugged system.

What debug data should be presented and where

IMO this is the biggest challange for the debug model implementation, simply because different embedded debuggers can have very different visual representations.

  • Debug model should allow arbitrary layouts of nodes representing debugger entities.
  • Ideally, debug views should allow the user to reconfigure the content and layout of various debug views to suit individual preferences. This seems like a strech, but the reality is that many of our users migrate from using very specialized debuggers which may have an unorthodox ways of presenting data. For such users it would be best to allow them to customize their views to match their working style.

Interoperability with 3rd party tools and standard clients

Even though many aspects of embedded debugging is unique to a given vendor/target configuration, etc, all of these debuggers share some common functionality found in standard debuggers (reading/writing memory, run control, stack retrieval, expression evaluation, etc).

  • Debug model should define a set of public APIs to access common debugger functionality, either by supporting existing APIs (Platform, CDI, JDI) or defining new ones.
  • If new APIs are defined, the model should have the ability to support legacy APIs: Platform, CDI, etc.

Update policies for debug data

Because of the lazy loading nature of the views, update policy has to be implemented by the model, and cannot be solved at the view level. Pushing this problem down to the model level doesn't solve all the issues, because the model itself will likely need to use lazy loading when retrieving data from a slow target, but at least it will allow for consistent information to be shown in the various views that are looking at the same data.

  • Debug model should provide a standard API for configurable update policies including auto update, manual update, and timed update.

Filtering and sorting of debug data

This is another problem that cannot be solved at the view level because of lazy loading. And even at the model level, many of the models may not be able to implement sorting or filtering because they may be limited by the capabilities of the target or out of process/JNI debugger back end.

  • Debug model should provide a standard API for sorting and filtering options.