<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.E-MailFormatvorlage19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.E-MailFormatvorlage20
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="DE" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Hm. Somehow Outlook botched the inline quotes of the html mail.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Does it work now?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:5.25pt"><b>Von:</b> Joel Sherrill <joel@rtems.org>
<br>
<b>Gesendet:</b> Mittwoch, 31. Januar 2024 16:57<br>
<b>An:</b> Karel Gardas <karel@functional.vision><br>
<b>Cc:</b> Frank Kühndel <frank.kuehndel@embedded-brains.de>; Sommer, Jan <Jan.Sommer@dlr.de>; devel@rtems.org<br>
<b>Betreff:</b> Re: Naming convention for Rust target platforms<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, Jan 31, 2024 at 12:31 AM Karel Gardas <<a href="mailto:karel@functional.vision">karel@functional.vision</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal">On 1/30/24 18:13, Frank Kühndel wrote:<br>
> Which name Rust accepts instead of "armv7a-rtems6-eabihf" depends on the <br>
> naming convention of the Rust community:<br>
> <a href="https://docs.rust-embedded.org/embedonomicon/custom-target.html" target="_blank">
https://docs.rust-embedded.org/embedonomicon/custom-target.html</a><br>
> According to this file, the part `eabi` is for bare metal. Would this be <br>
> correct when it is based on RTEMS? For example, a Linux target would be <br>
> "x86_64-unknown-linux-gnu" where `gnu` means started by 'glibc'.<br>
<br>
This is not completely fair to Jan as the x86_64 example is quite the <br>
exception instead of a common norm in rust platforms names. But you <br>
started with Linux so let's continue with Linux -- see the listing below.<br>
<br>
Also IMHO this convention is not about rust per se, but IMHO about LLVM <br>
way of doing things. GCC does that differently. So no C vs Rust, but GCC <br>
vs. LLVM. Once Rust in GCC happen it'll be done in GCC more RTEMS used <br>
way probably...<br>
<br>
So for Rust/LLVM I think Jan's proposal is about right except that I <br>
would strip '6' from rtems6. Neither OS (Linux, FreeBSD, NetBSD, <br>
Windows, OpenBSD, VxWorks, etc) uses any version notion in the OS name <br>
anyway... And also would strip 'a' from arm7a. We do not need to mention <br>
'a' here explicitly since for 'm' we do have whole family of 'thumb*' <br>
platform names... E.g. VxWorks in this particular case (ARMv7-A) uses: <br>
armv7-wrs-vxworks-eabihf<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">WRS took the vendor part of the triple and I would not judge correctness <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">on what they did.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I have reached out to a contact at a company that has a long history of<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">supporting the GNU tools and has added Rust to their services in the past<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">few years. I would like to hear their opinion. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US">Thanks a lot, so far I just used the armv7a-none-eabihf as a baseline and added<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">“rtems” to it as I was more focused on the actual porting. Now, for going official<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">I have to fix the annoying little details. My hope is that if we get a good<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">solution here once and accepted by the Rust community that this paves<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">the way for other ports. <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">If I understand your comments regarding binutils correctly then maybe<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Something like armv7-rtems-gnueabi(hf) would be more appropriate?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal">Cheers,<o:p></o:p></p>
<p class="MsoNormal"> Jan<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
Cheers,<br>
Karel<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On these, they actually do distinguish the OS. I see Linux, Android, and Open<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Harmony.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">There is also a distinction in the target name for C library used. I see glibc, <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">musl, and ulibc.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The rest of the target names are multilib variants and appear to reflect a lack <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">of support for or use of multilibs.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">IMO this naming seems to reflect a Linux focus and a lack of understanding<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">of the processor variations seen in the embedded world. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If this is the final pattern, it may work for RTEMS because people build their <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">own tools and tend to use 1-2 BSPs. But it will be painful for developers testing<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">multiple BSPs, etc. My cron sweeper builds almost 20 tool chains now. With this,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">we would be between 100 and 200 I expect. Some of the BSPs will have a similar <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">enough processor to share a tool chain but a lot won't.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I am glad you are working through this and this issue isn't a blocker for ironing<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">out a long list of other potential issues.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">--joel<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal"><br>
<br>
$ rustc --print target-list|grep linux<br>
aarch64-linux-android<br>
aarch64-unknown-linux-gnu<br>
aarch64-unknown-linux-gnu_ilp32<br>
aarch64-unknown-linux-musl<br>
aarch64-unknown-linux-ohos<br>
aarch64_be-unknown-linux-gnu<br>
aarch64_be-unknown-linux-gnu_ilp32<br>
arm-linux-androideabi<br>
arm-unknown-linux-gnueabi<br>
arm-unknown-linux-gnueabihf<br>
arm-unknown-linux-musleabi<br>
arm-unknown-linux-musleabihf<br>
armeb-unknown-linux-gnueabi<br>
armv4t-unknown-linux-gnueabi<br>
armv5te-unknown-linux-gnueabi<br>
armv5te-unknown-linux-musleabi<br>
armv5te-unknown-linux-uclibceabi<br>
armv7-linux-androideabi<br>
armv7-unknown-linux-gnueabi<br>
armv7-unknown-linux-gnueabihf<br>
armv7-unknown-linux-musleabi<br>
armv7-unknown-linux-musleabihf<br>
armv7-unknown-linux-ohos<br>
armv7-unknown-linux-uclibceabi<br>
armv7-unknown-linux-uclibceabihf<br>
csky-unknown-linux-gnuabiv2<br>
hexagon-unknown-linux-musl<br>
i586-unknown-linux-gnu<br>
i586-unknown-linux-musl<br>
i686-linux-android<br>
i686-unknown-linux-gnu<br>
i686-unknown-linux-musl<br>
loongarch64-unknown-linux-gnu<br>
m68k-unknown-linux-gnu<br>
mips-unknown-linux-gnu<br>
mips-unknown-linux-musl<br>
mips-unknown-linux-uclibc<br>
mips64-openwrt-linux-musl<br>
mips64-unknown-linux-gnuabi64<br>
mips64-unknown-linux-muslabi64<br>
mips64el-unknown-linux-gnuabi64<br>
mips64el-unknown-linux-muslabi64<br>
mipsel-unknown-linux-gnu<br>
mipsel-unknown-linux-musl<br>
mipsel-unknown-linux-uclibc<br>
mipsisa32r6-unknown-linux-gnu<br>
mipsisa32r6el-unknown-linux-gnu<br>
mipsisa64r6-unknown-linux-gnuabi64<br>
mipsisa64r6el-unknown-linux-gnuabi64<br>
powerpc-unknown-linux-gnu<br>
powerpc-unknown-linux-gnuspe<br>
powerpc-unknown-linux-musl<br>
powerpc64-unknown-linux-gnu<br>
powerpc64-unknown-linux-musl<br>
powerpc64le-unknown-linux-gnu<br>
powerpc64le-unknown-linux-musl<br>
riscv32gc-unknown-linux-gnu<br>
riscv32gc-unknown-linux-musl<br>
riscv64-linux-android<br>
riscv64gc-unknown-linux-gnu<br>
riscv64gc-unknown-linux-musl<br>
s390x-unknown-linux-gnu<br>
s390x-unknown-linux-musl<br>
sparc-unknown-linux-gnu<br>
sparc64-unknown-linux-gnu<br>
thumbv7neon-linux-androideabi<br>
thumbv7neon-unknown-linux-gnueabihf<br>
thumbv7neon-unknown-linux-musleabihf<br>
x86_64-linux-android<br>
x86_64-unikraft-linux-musl<br>
x86_64-unknown-linux-gnu<br>
x86_64-unknown-linux-gnux32<br>
x86_64-unknown-linux-musl<br>
x86_64-unknown-linux-ohos<br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><o:p></o:p></p>
</blockquote>
</div>
</body>
</html>