Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[dsdp-tm-dev] Re: Comment to http://wiki.eclipse.org/index.php/DSDP-TM_Proposal_for_RSE_Hierarchy_by_Dave_Dykstal_2005x11x09 
Thanks for your comments Uwe.
The Eclipse Wiki supports a "discussion" tab with each entry for such discussions. 
I've migrated your comments into that page.
I encourage all interested people to look at that page and enable Wiki "watch" for it 
such that we can all see when somebody adds some new thoughts.
Also, feel free to edit the page and add your own thoughts to the discussion. The little 
"+" sign in the tabs on the wiki will allow you to add a new section.

http://wiki.eclipse.org/index.php/Talk:DSDP-TM_Proposal_for_RSE_Hierarchy_by_Dave_Dykstal_2005x11x09

Cheers
Martin

Stieber, Uwe schrieb:


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



--
Martin Oberhuber
Wind River Systems, Inc.
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm

Back to the top