RE: [dsdp-tm-dev] Comment to http://wiki.eclipse.org/index.php/DSDP-TM_P

["Stieber, Uwe" <Uwe.Stieber@xxxxxxxxxxxxx>]

Hi Dave,
I've put it in here:
http://wiki.eclipse.org/index.php/RSE_2.0_Element_Hierarchy_Discussion
Cheers, 
Uwe Stieber

> -----Original Message-----
> From: dsdp-tm-dev-bounces@xxxxxxxxxxx 
> [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of David Dykstal
> Sent: Montag, 16. Oktober 2006 17:29
> To: Target Management developer discussions
> Subject: Re: [dsdp-tm-dev] Comment 
> tohttp://wiki.eclipse.org/index.php/DSDP-TM_Proposal_for_RSE_H
> ierarchy_by_Dave_Dykstal_2005x11x09
> 
> 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@xxxxxxx
> 
> 
> On Oct 16, 2006, at 10:21 AM, Stieber, Uwe wrote:
> 
> > 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
> > _______________________________________________
> > dsdp-tm-dev mailing list
> > dsdp-tm-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
> _______________________________________________
> dsdp-tm-dev mailing list
> dsdp-tm-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
>