[RFC] SBBR Test Case Additions to FWTS

[Alex Hung]

On Tue, Jan 10, 2017 at 11:19 AM, Jeffrey Hugo <jhugo at codeaurora.org> wrote:

> On 1/10/2017 11:17 AM, Leif Lindholm wrote:
>
>> Hi Jeffrey,
>>
>> On Tue, Jan 10, 2017 at 11:00:19AM -0700, Jeffrey Hugo wrote:
>>
>>> Once, the above two questions have been answered and we arrive at a
>>>> solution which is easier to maintain, will send out a list of patches
>>>> related to SBBR.
>>>>
>>>> Thanks in advance for your inputs.
>>>>
>>>
>>> Can you elaborate on the motivation for adding SBBR compliance to FWTS?
>>>
>>> SBBR is ARM specific, yet FWTS is architecture agnostic in its purpose.
>>> While my primary interest is ARM, it sounds like to add SBBR testing to
>>> FWTS
>>> requires the addition of a bunch of ARM specific tweaks that don't play
>>> well
>>> with other architectures.  Greater ARM support is nice, but not at the
>>> cost
>>> of not playing well with others.
>>>
>>
>> To clarify - this isn't a "test all of SBBR compliance using FWTS"
>> thing, it's a "test the bits that FWTS are already looking for, but
>> make the absence of certain tables result in reported test failures".
>>
>
> Hmm, I guess my perception of running the SBBR compliance testing is not
> accurate.
>
> Being that SBBR is ARM specific, and not even all ARM systems need to
> conform to SBBR as its a server specification (ie an ARM phone SoC), I
> personally do not feel as though changing the default behavior of FWTS is
> what I would like to see.
>
> SPCR for example, is an optional table per my reading of the ACPI spec.
> Therefore, I believe FWTS does the correct thing, today.  Since SBBR adds
> additional requirements, ie requires SPCR to be implemented, and and only
> applies to a small subset of FWTS consumers, then I feel that SBBR testing
> in FWTS should be an explicit thing that the user invokes - an "expert
> option" if you will.
>
> Off the top of my head, it would probably be more useful to me if SBBR
> were a separate test within FWTS (ie "fwts sbbr"), but a command line
> switch ("fwts --sbbr") seems acceptable to me.  Given that it sounds like
> FWTS does 95% of what you want already, the command line switch may be
> easier to implement.
>

​fwts has --uefitests (for all uefi tests) and --acpitests (for all acpi
tests), and I do not see problems with --sbbr or --sbbrtests for SBBR at all



>
> I guess that is a partial answer from be concerning Question 1 posed by
> Supreeth.  I would prefer option 1B.  I would not advise a separate branch
> as that seems to be a lot of cost for no real benefit as far as I can tell.
>
> Regarding question 2, I'm not sure what the issue with the SMBIOS test is,
> it currently works on our ARM64 platform.  If the issue is specific to the
> ARM arch as a whole, then compile time separation seems appropriate,
> however if the issue is specific to SBBR testing, then the switch should be
> done based on the fact that the user requested SBBR testing, since the
> issue won't apply to all platforms as discussed above.
>
> I think I'd need to see code addressing the issue with SMBIOS to comment
> more.
>
>
>> The other part of SBBR compliance validation runs in a UEFI SCT
>> context.
>>
>> Additionally, ARM (the company) has already published a SBBR compliance
>>> test
>>> at https://github.com/ARM-software/arm-enterprise-acs
>>>
>>> Why duplicate that in FWTS?
>>>
>>
>> Because that compliance test is based to a larger extent on FWTS and
>> ARM does not want to maintain a non-upstream branch in perpetuity if
>> it can be avoided.
>>
>> This pre-RFC is for investigating possibilities for getting away from
>> carrying patches against FWTS as part of that compliance test suite.
>>
>>
> Ah, sadly I haven't currently dug into the compliance test as much as I
> would like.  I see, so the test currently has a fork of FWTS, and you'd
> prefer to be using mainline for reasons which are now obvious. Motivation
> sufficiently explained.  Thank you.
>
> As a FWTS user, I'm interested to see where this goes.  I'm looking
> forward to seeing patches.
>
> --
> Jeffrey Hugo
> Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies,
> Inc.
> Qualcomm Technologies, Inc. is a member of the
> Code Aurora Forum, a Linux Foundation Collaborative Project.
>
> --
> fwts-discuss mailing list
> fwts-discuss at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/fwts-discuss
>



-- 
Cheers,
Alex Hung
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/fwts-devel/attachments/20170110/deefbc50/attachment-0001.html>