Skip to main content
Jump to: navigation, search

Difference between revisions of "DSDP/Packaging/Background"

Line 15: Line 15:
 
** Students - getting them acquainted with embedded technology easily
 
** Students - getting them acquainted with embedded technology easily
 
** Embedded Runtime Component vendors - who need an embedded host and tooling for their specific components to run, demo and evaluate on
 
** Embedded Runtime Component vendors - who need an embedded host and tooling for their specific components to run, demo and evaluate on
 +
 +
* Do we need to fear negative reactions from Embedded Vendors?
 +
** Unlikely in the beginning, because the target audience wouldn't spend money anyways
 +
** Probably even positive, because package would be building foundation for embedded vendors to base on more easily
 +
** If plain Open Source becomes "too good", vendors might start losing some customers, but that is normal as the commoditization bar is constantly rising anyways -- vendors need to stay on top of technology and offer competitive end-to-end solutions
 +
 +
===Interested Parties, who could help out?===
 +
* Distribution Builders - Cloudsmith, Yoxos, Pulse, Myeclipse, ...
 +
* Sign up your name here:
 +
** [[User:Martin.oberhuber.windriver.com|Martin Oberhuber]], Wind River
 +
** Doug Gaff, Wind River
  
 
==What should be in an Eclipse for Embedded Package?==
 
==What should be in an Eclipse for Embedded Package?==
Line 44: Line 55:
 
** Creating a package like [http://wascana.sourceforge.net/ Wascana] (CDT for Windows) on SourceForge, probably with P2 technology
 
** Creating a package like [http://wascana.sourceforge.net/ Wascana] (CDT for Windows) on SourceForge, probably with P2 technology
 
** Other packagers - [http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg02332.html Cloudsmith] has been discussed as an alternative
 
** Other packagers - [http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg02332.html Cloudsmith] has been discussed as an alternative
 
==Who is interested or could help out?==
 
* Silicon vendors: might even give away simple hardware boards for free, because they are interested in drawing people to their technology
 
* Software, component vendors
 
* Sign up your name here:
 
** [[User:Martin.oberhuber.windriver.com|Martin Oberhuber]], Wind River
 
** Doug Gaff, Wind River
 
  
 
==How could we make it happen?==
 
==How could we make it happen?==
Line 59: Line 63:
 
* Get in touch with Distribution builders like Cloudsmith, Yoxos, Pulse - they could help out with the packaging technology
 
* Get in touch with Distribution builders like Cloudsmith, Yoxos, Pulse - they could help out with the packaging technology
  
==Time Plan==
+
===Time Plan===
 
* Summer 2008 - Gather Community, Clarify requirements, work on first steps
 
* Summer 2008 - Gather Community, Clarify requirements, work on first steps
 
* Fall 2008 - Have a first package available (likely on Sourceforge)
 
* Fall 2008 - Have a first package available (likely on Sourceforge)
  
==Other open questions==
+
=Other open questions=
 
* How is [http://code.google.com/android/ Android] related?
 
* How is [http://code.google.com/android/ Android] related?
 +
* Edit the Wiki and '''post your question here''':
 +
** ??

Revision as of 08:48, 5 June 2008

DSDP Packaging Effort

Towards an Integrated Open "Eclipse for Embedded" Package

With commercial vendors, Eclipse has become a de-facto standard for integrated tooling for embedded software development. Much of these commercial solutions is bsed on the DSDP projects. But while the DSDP projects provide an impressive collection of features, it's hard to assemble them to a complete, working environment.

A single, integrated Open Source package for device software development built on top of the DSDP projects is still missing. What's holding us off from creating a DSDP package similar to what the EPP Project already provides for Java Devleopment, C/C++ Development, JEE Development and Reporting?

We've had a discussion about this with lots of people from the Community at the EclipseCon 2008 DSDP BoF Session, and some of the more interesting results of this discussion were (Raw Notes):

What is the target audience?

  • Everybody dealing with embedded technology, who doesn't want or cannot purchase a commercial solution:
    • Silicon vendors who'd like to give access to their stuff for free; they might actually help out with personnel, money, hardware or IT infrastructure, but we should remain Open and Vendor Neutral, not engage too much with one vendor
      • Still, even a Vendor Neutral Eclipse for Embedded Distribution could be a very interesting vehicle for Silicon Vendors to base their own stuff on, to simplify evaluation packages for them
    • Universities - offering courses for Embedded, they need some free tooling. The FIRST US Robotics competition is a similar example.
    • Students - getting them acquainted with embedded technology easily
    • Embedded Runtime Component vendors - who need an embedded host and tooling for their specific components to run, demo and evaluate on
  • Do we need to fear negative reactions from Embedded Vendors?
    • Unlikely in the beginning, because the target audience wouldn't spend money anyways
    • Probably even positive, because package would be building foundation for embedded vendors to base on more easily
    • If plain Open Source becomes "too good", vendors might start losing some customers, but that is normal as the commoditization bar is constantly rising anyways -- vendors need to stay on top of technology and offer competitive end-to-end solutions

Interested Parties, who could help out?

  • Distribution Builders - Cloudsmith, Yoxos, Pulse, Myeclipse, ...
  • Sign up your name here:

What should be in an Eclipse for Embedded Package?

  • Embedded Development can be separated in two, mostly mutually exclusive, areas and some generaly interesting related technology:
    • Embedded Java - MTJ, eRCP, Equinox, Eclipse Runtime Project
    • Embedded Native (C/C++) - CDT, Target Management, Device Debugging, NAB, TmL, RTSC, VPP, Orbit projects
    • Related Tooling Technologies
      • GNU tooling is a perceived standard (gcc, gdb, QEMU). But the license is incompatible with the EPL, how to handle that?
      • General editing support like Columns4Eclipse, see also bug 19771; Mylyn, Subversive
      • Emulations like QEMU, VirtualBox, VMWare, XEN and the like. TmL is working on a framework for these.
      • UI Toolkits - NAB and the MWT Libraries to be pre-installed on an Emulator; eRCP for Java
      • Multicore and connectivity - the Target Management project and especially the TCF Component are targeting these
      • System-on-a-chip, ESD Level simulation - the VPP project proposal is targeting these
      • Profiling, Performance monitoring - the TPTP project should be the foundation for this in Open Source, is it really applicable? Also has a runtime aspect, could TM TCF probably help?
      • Modeling - An increasing amount of embedded software is created with the help of Modeling tools like OpenArchitectureWare, UML, State Machines etc
    • Related Runtime Technologies
      • Pre-configured libraries or Kernels with Sources, pre-built, CDT indexer pre-build: For instance Linux Kernel; Embedded Linux from Code Sourcery, ACE+TAO, Free RTOS's?
      • UI Libraries - MWT for use with NAB, GTK, to be pre-installed on an Emulator; eRCP for Java
      • Networking emulations, middleware and the like -- again, TmL is investigating end-to-end simulation solutions.


  • Embedded tooling typically needs to be highly configurable -- different configurations based on desired target architecture and runtime components. We'd ultimately need an installer that can select and download the desired stuff only, packed in a nice UI. Could P2 be an option?


  • We should offer a simple basic self-contained package first. Out-of-the-box experience (OOBE) is more important than configurability here, since the OOBE is what we need to tackle with this effort.

Licensing and Distribution Questions

  • Embedded Development needs compilers and debuggers, which are typically in Open Source under GPL. The licensing incompatibility with the EPL forbids a single package like EPP hosted from Eclipse.org -- what are the alternatives?
    • Creating a package like Wascana (CDT for Windows) on SourceForge, probably with P2 technology
    • Other packagers - Cloudsmith has been discussed as an alternative

How could we make it happen?

  • A concrete plan should start with two simple self-contained packages:
    • DSDP for Java package - MTJ, eRCP and related stuff, probably Android as Emulator
    • DSDP for Native package - CDT, TM, DD, NAB, TML, QEMU, gcc, gdb - preconfigured for one specific target platform that comes pre-installed in QEMU
  • From that point on, we can gather more Community and work on more configurable packages or improved installers
  • Get in touch with Distribution builders like Cloudsmith, Yoxos, Pulse - they could help out with the packaging technology

Time Plan

  • Summer 2008 - Gather Community, Clarify requirements, work on first steps
  • Fall 2008 - Have a first package available (likely on Sourceforge)

Other open questions

  • How is Android related?
  • Edit the Wiki and post your question here:
    •  ??

Back to the top