YASL Request

Patrick Venture venture at google.com
Sat Apr 14 01:42:11 AEST 2018


On Fri, Apr 13, 2018 at 3:16 AM, Alexander Amelkin <a.amelkin at yadro.com> wrote:
> 12.04.2018 18:20, Patrick Venture wrote:
>> On Thu, Apr 12, 2018 at 7:25 AM, Alexander Amelkin <a.amelkin at yadro.com> wrote:
>>> 11.04.2018 05:34, Brad Bishop wrote:
>>>>> On Apr 9, 2018, at 6:27 PM, Patrick Venture <venture at google.com> wrote:
>>>>>
>>>>> Everyone,
>>>>>
>>>>> I'm working on unit-testing in openbmc, and have cracked most of
>>>>> sdbusplus into mockable pieces and verified I can in fact test against
>>>>> those mocks with a downstream daemon.  I'll be grabbing an upstream
>>>>>
>>>>> ...
>>>>>
>>>>> YASL (yet-another-shared-library) Request.
>>>> Can you talk more about what goes in this?
>>>>
>>>> Do you envision something like:
>>>>
>>>> openbmc repo -> upstream project being wrapped
>>>> libcmock -> glibc
>>>> libstdc++mock -> libstdc++
>>>> libsystemdmock -> libsystemd (or sdbusplusmock)
>>>> libfoomock -> libfoo
>>>> libbarmock -> libbarmock
>>>>
>>> Is there going to be support in the standard library to mock linux sysfs
>>> for phosphor-hwmon?
>> Yes, really we just need to mock the path look-ups and file reads.  So
>> if they ask to a list of files in a path, we can return whatever list
>> we want.
> Not really. We also need to support file writes that affect contents of
> other files (writing /sys/class/hwmon/.../pwmX affects the value read
> from /sys/class/hwmon/.../fanY). Without that some units will fail tests.

Yes really.  You just need to set the expectation that when it's read
it returns the value that it received in the mocked write call.  It's
a fairly normal pattern.


More information about the openbmc mailing list