On Fri, Aug 26, 2022 at 02:43:37PM +0000, Wei Yongjun wrote: > This series Introduce a BPF based SPI mockup controller, which can be > used for testing SPI drivers without real device. > > The testsuite for SPI drivers will be post in other series, with also > support for I2C and PCI bus device drivers. I replied to some of the individual patches here with some more detailed issues but I do have some big picture reservations with this approach as well. One big one is that this seems like it's only going to be able to handle emulation of devices that are purely synchronous - I don't see any sensible direction here for extending to devices that need an interrupt line as well. That seems like a major limitation. It's fine not to immediately implement everything but it should be fairly clear how that would be done when someone needs it and some of the BPF design goals I understood seem to conflict with that. I'm also not clear what the BPF environment is like when it comes to extensible frameworks, as soon as you start thinking about the problem space there are some obvious extensions with things like more detailed register map descriptions and validating that the operations that the driver is doing to the device are actually in spec for the device or trying to stimulate race conditions or error paths in the driver. There's also the issue with getting the BPF userspace tooling that I mentioned in reply to one of the individual patches. Basically while this does look very simple from a kernel point of view I worry that BPF might not be the right tool for the job and could be a bit of a blind alley, with people rapidly running into issues trying to do anything non-trivial. There was a series in the past year or so from someone implementing a similarish idea but rather than using BPF they provided a framework for writing device emulations in qemu with a simplified Python framework. That seemed like a more obvious direction here. They were initially focusing on I2C but it's a similar space. Unfortunately I'm drawing a blank on who was working on it or the name of the framework so I can't give a useful reference here. Their direction was towards having something that could also be used to validate what the driver was doing to the device from the device's perspective. I do know it was written up on LWN. Hopefully someone else will remember what I'm talking about from this vauge description.
Attachment:
signature.asc
Description: PGP signature
