Re: [osgi-dev] Correct processor types for ARM?
I agree but I am not sure any member has enough interest to drive that through a spec. It would still require the VMs to report it properly. Kind regards, Peter Kriens > On 13 Apr 2020, at 19:57, chris.g...@kiffer.be wrote: > > Hi Peter, > > I would argue that it is "os.arch" which is a bit of a mess, because it > attempts to represent too much in a single name. Compare this with the set > of "triples" here : > http://llvm.org/doxygen/classllvm_1_1Triple.html > > I would argue that these definitions would be a more useful way to specify > the target for native code, as they correspond to the way that code is > compiled for the various targets. > > Kind Regards > > Chris > > >> That is my experience on the ARM processor, there are so many variations, >> 32/64, le/be, floating point/no floating point, etc. that it is a bit of a >> mess. >> >> In general, on ARM I see people define the properties themselves to >> whatever the VM they use reports. >> >> Kind regards, >> >> Peter Kriens >> >> >>> On 13 Apr 2020, at 18:22, Markus Rathgeb via osgi-dev >>> wrote: >>> >>> This has been already done by someone here: >>> https://stackoverflow.com/a/57893125 >>> It seems os.arch is not really "stable" at all: >>> https://bugs.openjdk.java.net/browse/JDK-8167584 >>> ___ >>> OSGi Developer Mail List >>> osgi-dev@mail.osgi.org >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> ___ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > > ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Correct processor types for ARM?
On 2020-04-14T07:53:32 +0200 Tim Verbelen via osgi-dev wrote: > Hi Chris, Mark > > The beauty of the requirement-capability system is that you can easily > define these requirements and capabilities yourself, in addition to the > Bundle-NativeCode header (which is translated to a requirement anyway). > > Also, the full list of arch strings can be found at > https://www.osgi.org/developer/specifications/reference/#ReferenceOS Hello! Possibly a slight misunderstanding here: The issue isn't that I need to pick a string for my own usage. The issue is that, as a library author, I need to use _a string that matches what other people are using_. Due to a lack of standardization, there may not actually be any agreement here. Worse, the end-user of the bundle only gets to pick once (via setting os.arch) so if two bundles want to see different strings, one of them is going to fail to resolve. I did a bit of investigating, and it appears that OpenJDK builds use "arm" and "aarch64": https://github.com/AdoptOpenJDK/openjdk-jdk14u/blob/master/make/autoconf/platform.m4#L57 But in the past (according to LWJGL developers), JVMs have also used all of the following: arm arm32 armv6 armv7 aarch64 armv8 -- Mark Raynsford | https://www.io7m.com pgpA9vREH8UQk.pgp Description: OpenPGP digital signature ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Correct processor types for ARM?
Hi Chris, Mark The beauty of the requirement-capability system is that you can easily define these requirements and capabilities yourself, in addition to the Bundle-NativeCode header (which is translated to a requirement anyway). Also, the full list of arch strings can be found at https://www.osgi.org/developer/specifications/reference/#ReferenceOS Best regards, Tim On 4/13/20 7:57 PM, Chris Gray via osgi-dev wrote: Hi Peter, I would argue that it is "os.arch" which is a bit of a mess, because it attempts to represent too much in a single name. Compare this with the set of "triples" here : http://llvm.org/doxygen/classllvm_1_1Triple.html I would argue that these definitions would be a more useful way to specify the target for native code, as they correspond to the way that code is compiled for the various targets. Kind Regards Chris That is my experience on the ARM processor, there are so many variations, 32/64, le/be, floating point/no floating point, etc. that it is a bit of a mess. In general, on ARM I see people define the properties themselves to whatever the VM they use reports. Kind regards, Peter Kriens On 13 Apr 2020, at 18:22, Markus Rathgeb via osgi-dev wrote: This has been already done by someone here: https://stackoverflow.com/a/57893125 It seems os.arch is not really "stable" at all: https://bugs.openjdk.java.net/browse/JDK-8167584 ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev -- Tim Verbelen Senior Researcher at IDLab, Ghent University, in collaboration with imec tim.verbe...@ugent.be iGent | Technologiepark 126 9052 Ghent T: +32 9 33 14905 W: www.idlab.technology,www.imec-int.com ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Correct processor types for ARM?
Hi Peter, I would argue that it is "os.arch" which is a bit of a mess, because it attempts to represent too much in a single name. Compare this with the set of "triples" here : http://llvm.org/doxygen/classllvm_1_1Triple.html I would argue that these definitions would be a more useful way to specify the target for native code, as they correspond to the way that code is compiled for the various targets. Kind Regards Chris > That is my experience on the ARM processor, there are so many variations, > 32/64, le/be, floating point/no floating point, etc. that it is a bit of a > mess. > > In general, on ARM I see people define the properties themselves to > whatever the VM they use reports. > > Kind regards, > > Peter Kriens > > >> On 13 Apr 2020, at 18:22, Markus Rathgeb via osgi-dev >> wrote: >> >> This has been already done by someone here: >> https://stackoverflow.com/a/57893125 >> It seems os.arch is not really "stable" at all: >> https://bugs.openjdk.java.net/browse/JDK-8167584 >> ___ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > ___ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Correct processor types for ARM?
Hi Peter, I would argue that it is "os.arch" which is a bit of a mess, because it attempts to represent too much in a single name. Compare this with the set of "triples" here : http://llvm.org/doxygen/classllvm_1_1Triple.html I would argue that these definitions would be a more useful way to specify the target for native code, as they correspond to the way that code is compiled for the various targets. Kind Regards Chris > That is my experience on the ARM processor, there are so many variations, > 32/64, le/be, floating point/no floating point, etc. that it is a bit of a > mess. > > In general, on ARM I see people define the properties themselves to > whatever the VM they use reports. > > Kind regards, > > Peter Kriens > > >> On 13 Apr 2020, at 18:22, Markus Rathgeb via osgi-dev >> wrote: >> >> This has been already done by someone here: >> https://stackoverflow.com/a/57893125 >> It seems os.arch is not really "stable" at all: >> https://bugs.openjdk.java.net/browse/JDK-8167584 >> ___ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > ___ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Correct processor types for ARM?
That is my experience on the ARM processor, there are so many variations, 32/64, le/be, floating point/no floating point, etc. that it is a bit of a mess. In general, on ARM I see people define the properties themselves to whatever the VM they use reports. Kind regards, Peter Kriens > On 13 Apr 2020, at 18:22, Markus Rathgeb via osgi-dev > wrote: > > This has been already done by someone here: > https://stackoverflow.com/a/57893125 > It seems os.arch is not really "stable" at all: > https://bugs.openjdk.java.net/browse/JDK-8167584 > ___ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Correct processor types for ARM?
This has been already done by someone here: https://stackoverflow.com/a/57893125 It seems os.arch is not really "stable" at all: https://bugs.openjdk.java.net/browse/JDK-8167584 ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Correct processor types for ARM?
IIRC a RPi3B can run an 32 and 64 bit Linux system. I can try to run some tests, but I assume we need a "specification" instead of just sume examples. ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Correct processor types for ARM?
Hi Mark, I think you are correct. The processor values for the ARM family do not look sufficient to distinguish between 32-bit and 64-bit. It looks like the values now need to account for be vs le AND 32-bit vs 64-bit. The real question is how does Java running on these platforms report the value of the Java property "os.arch"? Does it accurately reflect the various combinations of possible ARM configurations? My guess is that we need to at least add 64-bit values for both ARM_le and ARM_be. But do we assume the "simple" values of ARM_le and ARM_be are 32-bit, or do these values now need to be deprecated like the original ARM value was? But if the Java implementations available for such environments does not distinguish the different combinations of ARM then I am not sure what values we should recommend here. I also do not have the available hardware to try this out myself. Tom - Original message -From: Mark Raynsford via osgi-dev Sent by: osgi-dev-boun...@mail.osgi.orgTo: osgi-dev@mail.osgi.orgCc:Subject: [EXTERNAL] [osgi-dev] Correct processor types for ARM?Date: Mon, Apr 13, 2020 9:03 AM Hello!Each time there's an LWJGL3 release, I repackage the modules as OSGibundles: https://github.com/LWJGL/lwjgl3 https://github.com/LWJGL/lwjgl3-osgiThe recent 3.2.3 release added support for ARM on Linux. Specifically,the release notes say: Linux: Added support for ARM builds. 32-bit: ARMv7/armhf architecture. Maven classifier: linux-arm32 64-bit: ARMv8/AArch64 architecture. Maven classifier: linux-arm64What are the correct definitions to use for Bundle-NativeCodedeclarations? I don't have any ARM hardware, so I won't know if I'vegotten the declarations wrong until someone tries and fails to resolvebundles on that hardware...The OSGi specifications seem to only mention ARM_le and ARM_be, whichseems insufficient.--Mark Raynsford | https://www.io7m.com attfg9n0.datType: application/pgp-signatureName: attfg9n0.dat ___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev attsdwgd.dat Description: Binary data ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
