Jump to: navigation, search

Difference between revisions of "DSDP/DD/DebugModel"

< DSDP‎ | DD
(Debugger for citizen monitoring system in George Orwell's 1984)
Line 11: Line 11:
 
: 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.   
 
: 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.   
  
==Theoretical embedded debugger model of God==
+
==Debugger for citizen monitoring system in George Orwell's 1984==
: Let's suppose there is a God somewhere out there, and this God has a pretty daunting task to perform: to monitor over 6,000,000,000 souls in the world, watch their deeds, listen to their prayers, count their sins, and of course issue judgment when the souls leave their bodies and are either sent to heaven, hell, or the ever popular pergutory. We would like to write a debugger for God, which would allow us to glimpse into the inner workings of the heavenly bodies, watch how God and his helper angels cope with this formidable task, and monitor their progress within our Eclipse-based debugger.   
+
: For those unfamiliar with the book.  In 1984, the citizen of Oceania live under the constant watchful eye of the Party and its leader Big Brother.  The Party has mandated that all citizen have a ''telescreen'' installed in their private home, 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.  
: Based on this simple model, we can already draw up some requirements that our debug model will have to meet in order to effectively monitor and debug God in his work:
+
: Designing the monitoring system was a formidable task, Oceania is a huge nation of hundreds of milions of citizen, 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 citizen and other Party members.  So most of the work of the monitoring system falls onto the automated monitoring system, based on latest microprocessor designs no doubt, which looks at everyone through all telescreens all the time and watches for signs of ''thoughtcrime''.
* ''There should be no assumptions about the number of objects that the debugger might need to track.''  It's not likely that the debugger will ever need to display information about the 6,000,000,000 souls in one view, but God is aware of all of them, and our debugger should be prepared to handle.  To tie this into a concrete embedded debugging use-case, we have systems which deal with very large data sets which need to be examined by the debugger, but which could easily overwhelm the amount of memory available on the host debugger.
+
: 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:
* ''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''.  Once again, the host debugger doesn't have the capacity to sort all of earth's souls according to the number of their sins, but God can probably do it in a jiff.  A concrete use case for this requirement is same as above.
+
* ''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 citizen 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 citizen, there is no way that a simple PC could store this much information, much less to process all of it.

Revision as of 17:49, 16 May 2006

This is the Debug Model Sub-group

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



Requirements discussion

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 solved. What 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.
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.

Debugger for citizen monitoring system in George Orwell's 1984

For those unfamiliar with the book. In 1984, the citizen of Oceania live under the constant watchful eye of the Party and its leader Big Brother. The Party has mandated that all citizen have a telescreen installed in their private home, 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.
Designing the monitoring system was a formidable task, Oceania is a huge nation of hundreds of milions of citizen, 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 citizen and other Party members. So most of the work of the monitoring system falls onto the automated monitoring system, based on latest microprocessor designs no doubt, which looks at everyone through all telescreens all the time and watches for signs of thoughtcrime.
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 citizen 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 citizen, there is no way that a simple PC could store this much information, much less to process all of it.