<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Joerg, Richard,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 17, 2021 at 10:37 PM Richard Palethorpe <<a href="mailto:rpalethorpe@suse.de" target="_blank">rpalethorpe@suse.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Joerg,<br>
<br>
Joerg Vehlow <<a href="mailto:lkml@jv-coder.de" target="_blank">lkml@jv-coder.de</a>> writes:<br>
<br>
> Hi,<br>
><br>
> On 11/17/2021 8:07 AM, Li Wang wrote:<br>
>> Testcases for specific arch should be limited on that only being supported<br>
>> platform to run, we now involve a .supported_archs to achieve this feature<br>
>> in LTP library. All you need to run a test on the expected arch is to set<br>
>> the '.supported_archs' array in the 'struct tst_test' to choose the required<br>
>> arch list. e.g.<br>
>><br>
>>      .supported_archs = (const char *const []){"x86_64", "ppc64", NULL}<br>
>><br>
>> This helps move the TCONF info from code to tst_test metadata as well.<br>
><br>
> while I do like this, I wonder if it wouldn't be better to do this<br>
> using kernel config. IIRC there are config switches<br>
> for all architectures. Further more this would allow adding more<br>
> complex conditions in the future.<br>
><br>
> E.g: I am pretty sure, that there are some syscalls, that have existed<br>
> "forever" in x86_64, but where only added<br>
> in a specific version for aarch64. By making the arch a separate<br>
> option, there is no way, to model this.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Umm, we shouldn't set .supported_archs to make it a separate option</div><div class="gmail_default" style="font-size:small">unless we have an explicit requirement on that. In other words, without</div><div class="gmail_default" style="font-size:small">that .supported_archs setting, it will support all arches by default and we</div><div class="gmail_default" style="font-size:small">can do anything by the exported tst_arch structure and enum tst_arch_type.</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">
> If it was done in the kernel config check, it could be possible to add<br>
> version and arch checks like<br>
> (CONFIG_AARCH64 && CONFIG_VERSION > 5.3) || CONFIG_X86_64<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">We definitely can achieve this in the current version as well.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">    switch (tst_arch.type)</div><div class="gmail_default" style="font-size:small">    case TST_AARCH64:</div><div class="gmail_default" style="font-size:small">            if ((tst_kvercmp(5, 3, 0)) < 0)</div><div class="gmail_default" style="font-size:small">                    break;</div><div class="gmail_default" style="font-size:small">    case TST_X86_64:</div><div class="gmail_default" style="font-size:small">            ltp_syscall(__NR_special_syscall, ...)</div><div class="gmail_default" style="font-size:small">    break;</div><div class="gmail_default" style="font-size:small">        ...</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">
><br>
> While this probably does not produce a very good error message, it is<br>
> more versatile.<br>
><br>
> Sorry for this late questioning the whole approach.<br>
<br>
It should never be too late IMO. We should also consider whether there<br>
are existing tst_test flags which have been made redundant by kconfig.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">After checking the config file again, yes, I agree that we can achieve the</div><div class="gmail_default" style="font-size:small">same thing just with existing kconfig functions to parse it. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">E.g. If required x86_64:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">    .needs_kconfigs = (const char *[]) {<br>        "CONFIG_X86_64=y",<br>        NULL<br>    },<br></div><br></div><div><div class="gmail_default" style="font-size:small">and s390x will be like:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">    .needs_kconfigs = (const char *[]) {<br>        "<span class="gmail_default"></span>CONFIG_64BIT=y",</div><div class="gmail_default" style="font-size:small">        "CONFIG_S390=y"<br>        NULL<br>    },<br></div><span class="gmail_default" style="font-size:small">  </span><br></div><div><span class="gmail_default" style="font-size:small">...</span></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>
I suspect the main issue would be meta-data. As an arbitrarily<br>
complicated kconfig expression may confuse test harnesses.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Right, so I would like to keep the .supported_archs and tst_arch structure</div><div class="gmail_default" style="font-size:small">no change, even though goes with parsing config file in the library.</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">
<br>
It might be better for us to tackle that issue and use kconfig though.<br>
<br>
-- <br>
Thank you,<br>
Richard.<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>