Hello Neil,
Neil Armstrong <[email protected]> writes: > On 10/2/26 09:37, Javier Martinez Canillas wrote: >> Neil Armstrong <[email protected]> writes: >> >> Hello Neil, >> >>> On 10/1/26 08:50, Maxime Ripard wrote: >> >> [...] >> >>>>> >>>>> I don't want to add a supplementary maintenance burden for the sake of >>>>> using a cool >>>>> technology which has serious drawbacks and dependencies on user-space >>>>> even if looks >>>>> really cool. >>>> >>>> Spoiler alert: v2 won't. I've got the in-kernel loader to work and thus >>>> you can have a built-in panel driver that works without user-space >>>> intervention. So this is not a topic of discussion anymore. >>> >>> It will still have users-space dependency, meaning the BPF files will need >>> to >>> exist in the fs when drivers probes. >>> >> >> It doesn't have to AFAIU. The BPF programs could be built into the kernel >> image, just like firmware binaries could be built-in as well. > > Right so my main question still is: what does it solve exactly ? > > All the descriptions I saw so far is that it simply moves > the panel C code to a BPF code with no other additions. > > I still don't have a clear view of what is precisely solves. > > It adds some complexity to load those BPF driver, adds some > maintenance complexities since with every API change we will > need validate BPF still works in addition to C (and maybe one day Rust). > https://www.kernel.org/doc/Documentation/bpf/bpf_design_QA.rst doc makes it clear that BPF programs can't expect the in-kernel API to be stable, so you as mantainer don't have constraints due the panel API being used by BPF programs. In other words, this shouldn't cause additional burden to you (other than the code in drm/panel/bpf/, but that is also true for any panel driver). > As the maintainer of the panels, merging a bunch of new panels at each > releases and helping migrating to newer and modern way to interact > with panels, I think I have the right to express my interrogations. > Absolutely. > I'm clearly not the oldest kernel contributor & maintainer around here, > but the main interrogation I have when submitting, reviewing and > merging is : does it really solve something efficiently. > It does. As mentioned, this could make it easier to have some panels working with an existing kernel without any modifications (or out-of-tree modules). I wouldn't say to prototype it, because as Maxime said, it could even be a proper support. But you get the idea. So just like sched_ext can be used to extend the scheduler (and some of those extensions might even end in some of the scheduling classes once are found to be generally useful), this driver could be used to quickly add support for new panels. > I don't want people to be frustrated by my review and question, > but I feel I'm allowed to say I'm not convinced about this solution. > Yes, of course. From a bystander, I think making assumptions or taking a decision prior to understanding the use case is what might had caused frustration. But as Maxime said, it would be helpful to have these discussions in person next week at LPC. I'll also be there, I'm looking forward to meet you in person. > Neil > -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
