<div dir="ltr"><div class="gmail_quote"><div> </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Quite the opposite, it should be an array of strings, so that it's easy<br>
> to work with such as:<br>
><br>
>       .supported_archs = (const char *const []){"x86_64", "ppc64le", NULL},<br>
><br>
> We can put it into a single string delimited by a space, but that would<br>
> be more complicated to work with.<br>
><br>
>> > However the hard part would be keeping the actual code and metadata in<br>
>> > sync, we still have to keep the ifdefs in the code.<br>
>> ><br>
>> <br>
>> Yes, some inline assemble require ifdefs.<br>
>> <br>
>> Btw, I look back at the reviews and find Jan said:<br>
>>     "I can see how tst_on_arch() would be useful. Test is valid<br>
>>      on all arches, but needs different input/constants/code/etc."<br>
>> <br>
>> That may be a slight reason for keeping tst_on_arch.<br>
><br>
> I guess that we should reviewe the code we have, I guess that there are<br>
> a few tests where we can get rid of a few ifdefs by doing the checks<br>
> dynamically.<br>
><br>
> Also I guess that it would be slightly easier to work with as an enum,<br>
> so that we can do:<br>
><br>
>       switch (tst_arch) {<br>
>       case TST_X86_64:<br>
>               ...<br>
>       break;<br>
>       case TST_PPC64_LE:<br>
<br>
I prefer enum as well. As an aside, we don't want to include LE in<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Sure, but I'm now thinking to extend the tst_arch as a structure</div><div class="gmail_default" style="font-size:small">so that could also be used in a string:</div><div class="gmail_default" style="font-size:small"><br></div><span class="gmail_default" style="font-size:small">    </span>enum tst_arch_type {<br>  <span class="gmail_default" style="font-size:small">            </span>TST_I386<span class="gmail_default" style="font-size:small">,</span><br>     <span class="gmail_default" style="font-size:small">            </span>TST_X86_64,<br>      <span class="gmail_default" style="font-size:small">            </span><span class="gmail_default" style="font-size:small">...</span></div><div><div class="gmail_default" style="font-size:small">            TST_SPARC,</div><span class="gmail_default" style="font-size:small">    </span>};<br><br><span class="gmail_default" style="font-size:small">    </span>/*<br> <span class="gmail_default" style="font-size:small">    </span>* This tst_arch is to save the system architecture for<br> <span class="gmail_default" style="font-size:small">    </span>* using in the whole test case.<br> <span class="gmail_default" style="font-size:small">    </span>*/<br><span class="gmail_default" style="font-size:small">    </span>extern struct arch {<br>        <span class="gmail_default" style="font-size:small">             </span>const char name[16];<br>   <span class="gmail_default" style="font-size:small">             </span>enum tst_arch_type type;<br><span class="gmail_default" style="font-size:small">    </span>} tst_arch;<br><br></div><div><div class="gmail_default" style="font-size:small">then we just can do simply in case:</div><div class="gmail_default" style="font-size:small"><br></div><span class="gmail_default" style="font-size:small">    </span>switch (tst_arch<span class="gmail_default" style="font-size:small">.type</span>) {<br><span class="gmail_default" style="font-size:small">    </span>case TST_X86_64:<br><span class="gmail_default" style="font-size:small">        </span>...<br><div class="gmail_default" style="font-size:small">    break;</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
ppc64. If someone finds that the byte order is significant for a test<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Yes, or we can read info via uname() into 'utsname.machine' for</div><div class="gmail_default" style="font-size:small">ppc64le if really needed.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
then we can add ppc64le or ppc64be. Also at some point we may need to<br>
add a "machine" field for e.g. POWER8, i386 etc.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Adding a new field '.machine' maybe not be necessary if just</div><div class="gmail_default" style="font-size:small">for POWER8/9/10, or can we find a way to combine them together</div><div class="gmail_default" style="font-size:small">with .supported_arch?  Umm, I'm still hesitating.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Which btw, I have some buildroot and QEMU scripts which can be used to<br>
test ppc64 BE and any other machine you have the hardware or QEMU<br>
emulator for.<br>
<br>
<a href="https://gitlab.com/Palethorpe/cross" rel="noreferrer" target="_blank">https://gitlab.com/Palethorpe/cross</a></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Thanks for sharing.</div></div><div><br></div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>