On Tue, 29 Sep 2026, Benjamin Tissoires <[email protected]> wrote: > Ouch. This immediately raises the "let's implement a parser in the > kernel" flag, or "let's create a new langage".
Fair. > You'd still need a dedicated driver for your new blob parser, with far > fewer people who had had a look at it than BPF who has been working on > for several years. Fair. > The integration of BPF and the kernel is honestly transparent nowaday: > calling a struct_ops BPF function is just a function call away, and from > the bpf calling anything in the kernel is also just a call away. I don't know if I'm just being overly conservative here, but it seems to me BPF provides too much flexibility for the use case. But maybe the point is completely moot, and you should just ignore me. ;) > See Maxime's answers: yes, falling back to dedicated driver is still > encouraged. [Moved the above to go with below.] > Isn't that what Maxime wants to have? One driver for a plethora of DSI > panels, with the same ability the BIOS has to also do function calls to > set things up? I suppose this is something that could use some clarification. Is the idea that most (simple) dedicated panel drivers eventually get converted to BPF? Or is the idea that BPF is easy for prototyping and development using stable kernels and short time to market, and most of them would eventually get converted to dedicated panel drivers? The story wrt display before userspace is up and running also needs clarification. BR, Jani. -- Jani Nikula, Intel
