[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-tm-dev] Sub-hosts with the Remote System Explorer
|
Hello Serge,
Connection Groups are just an idea (or probably little bit
More, but not yet a concrete plan). So there is no code for
It, and you cannot use it.
In a Subsystem, all the parent/child relationships are actually
Up to the Subsystem Implementer to provide. So it's up to you.
You can have users drag & drop DCU's across connections for
Isntance, in order to associate them with a host (in the DCU
Subsystem that you would provide).
Contributing a subsystem is not hard, and there is a good
Tutorial as well as example code available: Just download
The RSE Examples package, it has the "Developer Subsystem"
In there, the tutorial is at
http://dsdp.eclipse.org/help/latest/topic/org.eclipse.rse.doc.isv/guide/
tutorial/subsystem.html
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
> -----Original Message-----
> From: dsdp-tm-dev-bounces@xxxxxxxxxxx
> [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Serge Beauchamp
> Sent: Donnerstag, 24. April 2008 11:21
> To: Target Management developer discussions
> Subject: Re: [dsdp-tm-dev] Sub-hosts with the Remote System Explorer
>
> Hi Martin, Thanks a lot for your reply.
>
> From what I understand of the current RSE design, whether I
> specify DCU
> as belonging to a "connection group" or as subsystem of the
> target host,
> the user will not be able to configure through the UI which
> DCU should
> be attached to what target, is that right?
>
> In our case, the user can physically attach a variable amount
> of DCU to
> a given hardware board. The need to model this relation in the RSE
> would be valuable for us in many scenarios, including:
>
> When configuring a performance measurement session, the user could
> specify only what DCU to use and the software component would know
> automatically what are the target settings by looking in the
> RSE tree to
> which target this DCU is attached to.
>
> From what I understand, it is not possible currently for the user to
> define which host belong to what group or to manually create new
> subsystems, right?
>
> I will try to contribute to the wiki page you mention about
> our use cases.
>
> Serge Beauchamp
> Software Engineer
> Freescale Semiconductor
>
> Oberhuber, Martin wrote:
> > Hello Serge,
> >
> > This is a good question. I think it really boils down to
> > where you want the Subsystem level to be.
> >
> > Let's assume an OS Awareness Subsystem that gives you
> > information about the Threads running on your hardware.
> >
> > You can have one master subsystem showing all threads
> > regardless of DCU they run on. Then the Target is your
> > IHost. Or, you can have separate subsystems on each of
> > the DCUs. Then each DCU is a host of itself, and what
> > you need is Target Grouping in order to group the
> > separate DCUs (Ihost objets) under a single parent.
> >
> > We've had some discussions about connection grouping
> > a long time ago,
> > http://wiki.eclipse.org/DSDP/TM/Connection_Groups
> >
> >
> http://wiki.eclipse.org/DSDP-TM_Proposal_for_RSE_Hierarchy_by_
> Dave_Dykst
> > al_2005x11x09
> >
> > I'd love to see these discussions get active again.
> >
> > I think what's really missing right now is a much
> > clearer picture of the use-cases related to multi-target
> > and connection grouping. Could you start filling in your
> > envisioned system on the "Connecton Groups" Wiki page?
> >
> > I think that one guideline here can be that a
> > "Conenction Groups" concept which merely groups several
> > independent IHost connections will always be a light
> > coupling between the IHosts only.
> >
> > For systems that have a tight coupling between the
> > various (co)devices on a board, a single subsystem
> > giving access to those (co)devices might be the
> > better approach.
> >
> > The "connection group" approach will likely require
> > API changes in RSE, in order to support multiple levels
> > if nesting in the SystemView before the IHost objects
> > are shown. But it might also work without API changes.
> >
> > The "subsystem" approach is totally up to each extender
> > of RSE to implement by himself.
> >
> > Hope that helps for now, let's get the discussion going!
> >
> > Cheers,
> > --
> > Martin Oberhuber, Senior Member of Technical Staff, Wind River
> > Target Management Project Lead, DSDP PMC Member
> > http://www.eclipse.org/dsdp/tm
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: dsdp-tm-dev-bounces@xxxxxxxxxxx
> >> [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of
> Serge Beauchamp
> >> Sent: Mittwoch, 23. April 2008 13:40
> >> To: dsdp-tm-dev@xxxxxxxxxxx
> >> Subject: [dsdp-tm-dev] Sub-hosts with the Remote System Explorer
> >>
> >> Hi,
> >>
> >> I've been looking in the Remote System Explorer feature, and
> >> we'd like
> >> to use it to be able to model the hardware setup that our
> >> customers are
> >> using.
> >>
> >> Basically, the typical setup consist of a hardware board
> (the target)
> >> and a numbers of Data Collection Units (DCU) setup for the
> target.
> >>
> >> In the RSE, I understand that the target would need to be
> >> represented as
> >> a host, but since the DCU are different boards with their own
> >> IP and can
> >> be reconfigured for a different host, it seems that they
> >> don't fit the
> >> RSE model as being sub-systems of the host but rather hosts
> >> themselves, no?
> >>
> >> Ideally, I would like to be able to specify the DCU as
> >> children of each
> >> target, while the user can re-parent them or move them at top
> >> level if
> >> necessary, is that possible with the current RSE design?
> >>
> >> Thanks.
> >>
> >> Serge Beauchamp
> >> Software Engineer
> >> Freescale Semiconductor
> >> _______________________________________________
> >> 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
> >
> _______________________________________________
> dsdp-tm-dev mailing list
> dsdp-tm-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
>
