harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [general] platform support
Date Sat, 12 Aug 2006 02:10:27 GMT

Elford, Chris L wrote:
> Any _primary_ platform that will be supported by Harmony will probably
> need to be put thru a pretty full test protocol on that platform
> independent of whether it uses the same binary or a different binary. 

Yes - the testing for a given platform is independent of the platform.

> I
> doubt that the Harmony community will want to target all possible OS
> combinations initially.  I think that we should have a serious
> discussion on this list about the OS combinations for which we have
> "volunteers on board" for "Harmony 1.0".

We are having one.

> I don't believe that Harmony should achieve ubiquity by using least
> common denominator interfaces.  For x86 32bit-mode systems, I do think
> we'll probably need to limit ourselves to one or two binaries.

Hang on - do you think anyone is advocating ubiquity via LCD interfaces?
 What we needed was a focused discussion on the technological
trade-offs,  and I think we're having one.

> See http://java.sun.com/j2se/1.5.0/system-configurations.html and
> http://edocs.bea.com/jrockit/jrdocs/suppPlat/supp_50.html a list of what
> combinations Sun and BEA support today with their Java5 solutions.
> I am unconvinced that a combined binary will make testing any easier.  

I think you are focusing on the wrong argument or something. I don't
think anyone is seriously suggesting we'd do that for testing purposes,
because we have to test on any platform we claim to support.  The
combined binary will make life easier for users and distributors.

This started as a debate over whether or not we will even support win2k,
 because people were trying to use harmony on it.

> believe that the makefile (oops, I mean ant) structure will be easier
> with a combined binary but the startup code and some platform specific
> optimization code will be more complex as it will need a pretty
> sophisticated platform determination and a somewhat manual library
> loading process.  At the same time, I believe a combined binary that
> includes multipath checks will simplify distribution.  I also believe
> that something similar will be necessary for Linuxes though perhaps not
> as sophisticated.

Right.  Exactly.

> Lets say that we decide to go for "complete", "optimal", windows
> support.  We would have special case code that chooses appropriate
> library interfaces at startup for somewhere between 7 and 18 different
> versions of x86 windows, not accounting for service packs:
> * x86 Vista home, pro, tablet
> * x86 Vista/Longhorn server, webserver
> * x86 Vista/longhorn enterprise

Do you think this software will ever be released? :)  It would be
interesting to see if what we have even runs on Vista....

> * x86 XP home, pro, tablet, media
> * x86 XP/2003 server, webserver, Enterprise, Datacenter
> * x86 W2K 
> * x86 W2K Server, W2K Advanced Server, Datacenter
> This of course doesn't account for the either EM64T or Itanium family
> processor based systems.  Maybe someone needs to take each OS platform
> and list what special interfaces are useful for each one.  I'm
> particularly partial to some of the interfaces available only on the
> server versions such as the large page APIs:
> http://windowssdk.msdn.microsoft.com/en-us/library/ms694004.aspx.
> http://windowssdk.msdn.microsoft.com/en-us/library/ms724833.aspx talks
> about how to distinguish the different versions and service packs from
> each other.  This is probably pretty useful information to report back
> to JIRA in the case of a VM crash if we have a single binary release
> model.  Of course if one wants to be able to run on windowsMe or
> Windows98, one can't rely on these interfaces...  But then since these
> aren't actively supported by Microsoft anymore, its unclear how relevant
> those platforms are.  

I think fairly irrelevant, but if someone did step up and wanted to do
the work, I wouldn't stand in their way :)


Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message