Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[dsdp-tm-dev] RE: openSolaris ? What is the story ?

Hi Gary,
The target environment entry "SOlaris - SPARC" only says that this is where we happen to
have a box and do some testing of the CLIENT (but not dstore).
Why do you think that companies need to have 500+ employees to contribute?
Everybody, including individuals, can contribute by just submitting a patch.
For getting set up with a development environment for RSE, see the FAQ:
I'll be on vacation now for 2 weeks but other committers will certainly help you.
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member

From: gary mazzaferro [mailto:garym@xxxxxxxxxx]
Sent: Montag, 22. Juni 2009 16:16
To: Oberhuber, Martin
Cc: Target Management developer discussions
Subject: Re: openSolaris ? What is the story ?

HI Martin,

Thanks for the quick reply and pointers to the project plan. As I mentioned in the email, my focus was on PTP and not RSE. My involvement with RSE was only a result of a dependency from PTP. --- I didn't read the plan.

I noticed that you were going/are supporting  Solaris 10, which IS opensolaris. The plan also shows support for Sparc processors  which could be an expensive proposition in comparison to a $300 pc. Both Solaris 10 and opensolaris operate on a x86-64 platform, the ARM platform is ready to go. Additionally, opensolaris operates in a few different VMs, Virtualbox and Xen (open source) being a couple to mention. of them. What I'm trying to say is the huge expense of requiring a Sparc platform is no longer required to support Solaris.  It can be downloaded for free at

I looked at the rdt code, it doesn't seem that difficult to add the functionality to the server. I'll probably that a swipe at it this week. We are a small development consultancy with plenty of expertise in C/C++ kernel and vxworks development. We are not Java developers.  For us to look at  this problem is difficult decision, we don't have the scale to sponsor eclipse. We have to make the decision of working on a project that's going to put food on the table or work on a project where we have very little expertise, that may help us next year. If the economy was better, supporting open source was an easy decision, now "not so much".

I also looked at  Create Dialog bug, I think I figured it out. The project name is not being appended to the directory name as with the local project creation. You need to treat the remote directory as the destination for the project files. The 2.0 RSE or the 3.4 platform handled this differently. Recocidering, its not really a bug, if the behavior is documented.

We would normally fix these two issues ourselves and release the code back to the community, if we had the eclipse expertise. But I feel the eclipse board did a very good job of ensuring eclipse became so complex,  only companies larger than 500 people can seriously consider contributing to eclipse projects. 

I'll try to get the Dstore feature fixed this week. I'll need some direction...

The idea that you need Sparc to support opensolaris is wrong, most opensolaris adoption is on x86-64.



On Mon, Jun 22, 2009 at 6:36 AM, Martin Oberhuber <martin.oberhuber@xxxxxxxxxxxxx> wrote:
Hello Gary,

In general, committers can only provide support on target hardware that they have access to. None of us has any openSolaris box, so all we can do is assist you in fixing the problems yourself. We will happily help you through your issues as much as we can, but don't expect us to fix and test the code for you since we don't have the target platforms available.

I assume that you are talking about
[dstore] Processes do not work on Dstore-UNIX connection to Solaris

You'll notice that this bug has been marked as "helpwanted" for the
very reason I gave above for some time. We are willing to help end-users
fix the issue themselves, and we are willing to accept patches. But
since we don't have the solaris hardware, and since our employers don't use it, you have to understand that it is not our top priority.

Our official reference platforms are listed on
and you'll see that solaris has never been a reference platform for
dstore. Which means we cannot routinely test it. But we can and will
still help our clients. Eclipse is a "Community" -- come be part of it!

Please use the mailing list, file bugs or comment on existing bugs,
and we will help you getting set up to start fixing things yourself.
I personally don't think the solaris dstore processes issue is a tremendously hard one to fix, provided one has the machine available... I just added some notes on the bug 175293 mentioned above.

For your 2nd issue, "can create a project on opensolaris with the eclipse sdk 3.4 but not with eclipse sdk 3.5.", it looks like you'll
want to file a new bug. Again, try to be as specific as you can.
will file the bug against the right product.

Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member

gary mazz wrote:

I posted this on eclipse.dsdp, but reading though the list, I noticed a message saying "this" is the real list.

I'm trying to use RSE with opensolaris 2009.06. I was actually trying to use PTP which has a dependency on RSE. I've been working with the PTP/CDT group for the past week isolating the issues, multiple installs, matrix-ing the packages, etc. I spent about 30hrs working though the integration issues.

With the aid of the very helpful PTP team, we were able to isolate my ptp problems down to RSE.

I can create a project on opensolaris with the eclipse sdk 3.4 but not with eclipse sdk 3.5. I also can't build on any versions of RSE or of the eclipse sdks. Additionally, if I attempt to browse the processes, it throws and exception.
Searching the posts, it seems like the solaris process bug is open and unfixed since Feb, 2007.
The real question is will opensolaris be supported by the RSE team ? or did I just waste of week of time ?


Back to the top