linux-kernel - Re: [RFC PATCH v4 1/4] fpga: add fake FPGA manager

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 4 May 2023 20:25:32 +0800
From:   Xu Yilun <yilun.xu@...el.com>
To:     Marco Pagani <marpagan@...hat.com>
Cc:     Moritz Fischer <mdf@...nel.org>, Wu Hao <hao.wu@...el.com>,
        Tom Rix <trix@...hat.com>, linux-kernel@...r.kernel.org,
        linux-fpga@...r.kernel.org
Subject: Re: [RFC PATCH v4 1/4] fpga: add fake FPGA manager

On 2023-05-03 at 18:53:02 +0200, Marco Pagani wrote:
> On 2023-04-26 17:44, Marco Pagani wrote:
> > 
> > 
> > On 2023-04-20 20:31, Xu Yilun wrote:
> >> On 2023-04-17 at 14:23:05 +0200, Marco Pagani wrote:
> >>> Add fake FPGA manager platform driver with support functions.
> >>> The driver checks the programming sequence using KUnit expectations.
> >>> This module is part of the KUnit tests for the FPGA subsystem.
> >>>
> >>> Signed-off-by: Marco Pagani <marpagan@...hat.com>

[...]

> >>> +EXPORT_SYMBOL_GPL(fake_fpga_mgr_check_write_sgt);
> >>
> >> I'm wondering, if we could move all these exported functions out of
> >> fake_fpga driver module. And make this driver module serves FPGA
> >> mgr framework only, just like other fpga drivers do.
> >>
> >> I assume the main requirement is to check the statistics produced
> >> by the fake fpga driver. Directly accessing mgr->priv outside the
> >> driver could be unwanted.  To solve this, could we create a shared
> >> buffer for the statistics and pass to fake drivers by platform data.
> >>
> >> I hope move all the tester's actions in fpga-test.c, so that people
> >> could easily see from code what a user need to do to enable fpga
> >> reprogramming and what are expected in one file. The fake drivers could
> >> be kept as simple, they only move the process forward and produce
> >> statistics.
> >>
> >> Thanks,
> >> Yilun
> >>
> > 
> > I agree with you. Initially, I wanted to keep all KUnit test assertions
> > and expectations contained in fpga-test. However, I could not find a simple
> > way to test that the FPGA manager performs the correct state transitions
> > during programming. So I ended up putting KUnit assertions in the methods
> > of the low-level fake driver as a first solution.
> > 
> > I like your suggestion of using a shared buffer to have a cleaner
> > implementation. My only concern is that it would make the code more complex.
> > I will work on this for V5.
> > 
> 
> I experimented with a couple of alternatives to move all tests inside
> fpga-test and remove the external functions. Unfortunately, each alternative
> comes with its drawbacks.
> 
> Using a shared buffer (e.g., kfifo) to implement an events buffer between
> fake mgr/bridge and the fpga-test overcomplicates the code (i.e., defining
> message structs, enums for the operations, locks, etc.).

Oh, I actually didn't expect a message based mechanism for statistics
reading, which is overcomplicated for a test.

Maybe just pass a structured data buffer via platform_data, so that both
fpga-test & fake drivers could recognize and access it directly. fpga-test
could directly check the updated statistics after reprograming and assert
them. Is that OK for you?

Thanks,
Yilun

> 
> Moving fake modules' (mgr, bridge, region) implementations inside fpga-test
> makes fpga-test monolithic and harder to understand and maintain.
> 
> Accessing modules' private data directly from fpga-test breaks encapsulation.
> 
> Overall, it seems to me that using external functions to get the state of fake
> modules is the least-worst alternative. What are your thoughts and preferences?
> 
> Thanks,
> Marco
> 
> 
> >>> [...]
>