Skip to main content
Jump to: navigation, search

Difference between revisions of "RSE 2.0 Element Hierarchy Discussion"

m
Line 15: Line 15:
 
Since you are doing an actual implementation what you come up with   
 
Since you are doing an actual implementation what you come up with   
 
will probably be more correct for you.
 
will probably be more correct for you.
<p>
+
<br>
 
I'll sit down with this and see what I can do to generate   
 
I'll sit down with this and see what I can do to generate   
 
requirements against RSE from it.
 
requirements against RSE from it.
<p>
+
<br>
 
It might be a good idea to post this in the R2.0 discussion wiki.
 
It might be a good idea to post this in the R2.0 discussion wiki.
<p>
+
<br>
 
Dave Dykstal<br>
 
Dave Dykstal<br>
 
dykstal@acm.org
 
dykstal@acm.org
Line 28: Line 28:
 
Hi David,
 
Hi David,
 
I have a comment to the RSE hierarchy proposal (as you have asked for at the TWiki page).  
 
I have a comment to the RSE hierarchy proposal (as you have asked for at the TWiki page).  
<p>
+
<br>
 
First a question: How should a discussion about the documents be handled? I cannot simple change it in TWiki (well I can technically of course), can I? As the document is owned explicitly by you, it should be changed only by you, shoudn't it?
 
First a question: How should a discussion about the documents be handled? I cannot simple change it in TWiki (well I can technically of course), can I? As the document is owned explicitly by you, it should be changed only by you, shoudn't it?
<p>
+
<br>
 
Well, as for the hierarchy, for our product, we have to deal more or less with three different hierarchies. 2 of them (2 and 3) are known requirements but not yet available in the product as we had to deal with other issues.
 
Well, as for the hierarchy, for our product, we have to deal more or less with three different hierarchies. 2 of them (2 and 3) are known requirements but not yet available in the product as we had to deal with other issues.
<p>
+
<br>
 
'''1)''' This is our current hierarchy we would like support still with RSE (2.0?) simply for workflow reasons to our users/customers (small adjustments might be possible, see 4)). We would like to be able to introduce user definable filters on every level.
 
'''1)''' This is our current hierarchy we would like support still with RSE (2.0?) simply for workflow reasons to our users/customers (small adjustments might be possible, see 4)). We would like to be able to introduce user definable filters on every level.
<p>
+
<br>
 
<pre>
 
<pre>
 
<Network Shared Connection Store>
 
<Network Shared Connection Store>
Line 55: Line 55:
 
<...> (other possible types might be having there own childs>
 
<...> (other possible types might be having there own childs>
 
</pre>
 
</pre>
<p>
+
<br>
 
'''2)''' This is matching to the wish of connection groups. We have this requirement since a while, but have not yet worked on it since it become clear that we should base on RSE. We would like to group more or less a free definable collection of connections or cores.
 
'''2)''' This is matching to the wish of connection groups. We have this requirement since a while, but have not yet worked on it since it become clear that we should base on RSE. We would like to group more or less a free definable collection of connections or cores.
<p>
+
<br>
 
<pre>
 
<pre>
 
<Network Shared Connection Store>
 
<Network Shared Connection Store>
Line 68: Line 68:
 
...
 
...
 
</pre>
 
</pre>
<p>
+
<br>
 
or
 
or
<p>
+
<br>
 
<pre>
 
<pre>
 
<Network Shared Connection Store>
 
<Network Shared Connection Store>
Line 87: Line 87:
 
...
 
...
 
</pre>
 
</pre>
<p>
+
<br>
 
or a combination of both.
 
or a combination of both.
<p>
+
<br>
 
'''3)''' Is more or less a extension to '''2)'''. It's the idea of shared board labs which may export/group network shared connection stores or connections. Of course, number 2 still applies here for everything below the stores.
 
'''3)''' Is more or less a extension to '''2)'''. It's the idea of shared board labs which may export/group network shared connection stores or connections. Of course, number 2 still applies here for everything below the stores.
<p>
+
<br>
 
<pre>
 
<pre>
 
<Shared Board Lab 1>
 
<Shared Board Lab 1>
Line 108: Line 108:
 
...
 
...
 
</pre>
 
</pre>
<p>
+
<br>
 
'''4)''' We do have a very rough prototype running, which is more or less contributing to what RSE 1.0 like to see as hierarchy. It looks quite promising, but as it require to introduce a synthetic level to the hierarchy, which makes it looking not fully satisfying at the end.
 
'''4)''' We do have a very rough prototype running, which is more or less contributing to what RSE 1.0 like to see as hierarchy. It looks quite promising, but as it require to introduce a synthetic level to the hierarchy, which makes it looking not fully satisfying at the end.
<p>
+
<br>
 
The hierarchy of the prototype is:
 
The hierarchy of the prototype is:
<p>
+
<br>
 
<pre>
 
<pre>
 
<connection identified by a name> (== system type)
 
<connection identified by a name> (== system type)
Line 122: Line 122:
 
...
 
...
 
</pre>
 
</pre>
<p>
+
<br>
 
The sub system level is obsolete and hindering (to us) as it only satisfies the hierarchy (from our point of view). It would be ok to keep the hierarchy of system type and sub system if a sub system can have the attribute "hidden" and the content provider would kind of skip the node within the tree.
 
The sub system level is obsolete and hindering (to us) as it only satisfies the hierarchy (from our point of view). It would be ok to keep the hierarchy of system type and sub system if a sub system can have the attribute "hidden" and the content provider would kind of skip the node within the tree.
<p>
+
<br>
 
Best regards,
 
Best regards,
<p>
+
<br>
 
--<br>
 
--<br>
 
Uwe Stieber<br>
 
Uwe Stieber<br>
 
Member of Technical Staff<br>
 
Member of Technical Staff<br>
 
Engineering - Wind River Systems - Austria<br>
 
Engineering - Wind River Systems - Austria<br>

Revision as of 02:35, 17 October 2006

RSE Element Hierarchy Discussion

This discussion topic is based on the posted document DSDP-TM Proposal for RSE Hierarchy by Dave Dykstal 2005x11x09. The purpose of this topic is to collect comments and visions for the RSE element hierarchies.


Discussion


Uwe --

Thanks for looking at that hierarchy. I did that quite a long time ago as a sort of conceptual look at what I thought might be useful. Since you are doing an actual implementation what you come up with will probably be more correct for you.
I'll sit down with this and see what I can do to generate requirements against RSE from it.
It might be a good idea to post this in the R2.0 discussion wiki.
Dave Dykstal
dykstal@acm.org


Hi David, I have a comment to the RSE hierarchy proposal (as you have asked for at the TWiki page).
First a question: How should a discussion about the documents be handled? I cannot simple change it in TWiki (well I can technically of course), can I? As the document is owned explicitly by you, it should be changed only by you, shoudn't it?
Well, as for the hierarchy, for our product, we have to deal more or less with three different hierarchies. 2 of them (2 and 3) are known requirements but not yet available in the product as we had to deal with other issues.
1) This is our current hierarchy we would like support still with RSE (2.0?) simply for workflow reasons to our users/customers (small adjustments might be possible, see 4)). We would like to be able to introduce user definable filters on every level.

<Network Shared Connection Store>
	<Connection 1>
	<Connection 2>
		<Core 1>
			<Processes> (for Linux targets)
				<Process 1>
					<Thread 1>
					<Thread n>
				<Process n>
		...
		<Core n> (possibly multi core targets)
	<Connection 3>
		<Core 1>
			<Kernel Tasks> (for vxWorks targets)
				...
			<Real Time Processes> (for vxWorks targets)
				...
			<...> (other possible types might be having there own childs>


2) This is matching to the wish of connection groups. We have this requirement since a while, but have not yet worked on it since it become clear that we should base on RSE. We would like to group more or less a free definable collection of connections or cores.

<Network Shared Connection Store>
	<Target Connection Group Target 1>
		<Connection 1 to Target 1> (purpose user mode debugging)
			<Core 1>
				...
		<Connection 2 to Target 1> (purpose system mode debugging or system bring up)
			<Core 1>
				...


or

<Network Shared Connection Store>
	<Connection 1>
		<Target Core Group "Engine Control">
			<Core 1>
				...
			<Core 2>
				...
			<Core 3>
				...
		<Target Core Group "Entertainment">
			<Core 4>
				...
			<Core 5>
		...


or a combination of both.
3) Is more or less a extension to 2). It's the idea of shared board labs which may export/group network shared connection stores or connections. Of course, number 2 still applies here for everything below the stores.

<Shared Board Lab 1>
	<Network Shared Connection Store 1>
	<Network Shared Connection Store 2>
		...
	<Network Shared Connection Store n>
<Shared Board Lab 2>
	<Grouped by criteria (i.e. architecture>
		<Network Shared Connection Store 1>
		<Network Shared Connection Store 2>
		<Connection 1>
		<Connection 2>
		...
	<Grouped by other criteria (i.e. booted Target OS)
		...


4) We do have a very rough prototype running, which is more or less contributing to what RSE 1.0 like to see as hierarchy. It looks quite promising, but as it require to introduce a synthetic level to the hierarchy, which makes it looking not fully satisfying at the end.
The hierarchy of the prototype is:

<connection identified by a name> (== system type)
	<WR Debugger> (== sub system)
		<Filter (All Cores)>
			<Core 1>
				<Processes>
					...
			...


The sub system level is obsolete and hindering (to us) as it only satisfies the hierarchy (from our point of view). It would be ok to keep the hierarchy of system type and sub system if a sub system can have the attribute "hidden" and the content provider would kind of skip the node within the tree.
Best regards,
--
Uwe Stieber
Member of Technical Staff
Engineering - Wind River Systems - Austria

Back to the top