On Wed, 30 Sept 2026 at 15:57, Neil Armstrong <[email protected]> wrote: > > [...] > >>> > >>> Changing the mindset is the hardest part of it. But once you are making > >>> the shift, it's actually much better to work with. It doesn't mean you > >>> can go yolo. You still need to be careful in your choices knowing the > >>> impact on your users. But the API at version 0 is not frozen and you > >>> don't need to maintain it forever, especially if you control the loader > >>> and the headers used to compile the BPFs. > >> > >> It's really impressive, but there's no way this would become the de-facto > >> way to program the panels > > > > Nobody said it would? And like I said in my previous mail, I actually > > expect us to keep merging panel drivers. Do I think it should become the > > go-to solution for simple panels? yes. But we can always make > > exceptions, and for more complex panels we should totally do a more > > complex driver. Like HID has been doing. > > > >> and if the motivation is to make it simpler this implementation > >> requires adding bindings and bpf programs which that are the same as > >> native panel drivers, but won't be able to work until user-space > >> starts and will require to be in initramfs or rootfs to have > >> functional display. > >> > >> Not sure to understand what are the positive features here except > >> isolating the panel code in a safe bpf program (is this really needed > >> ?). > > > > From the cover letter: > > > > """ > > Panels in general, and MIPI-DSI panels in particular, are pretty > > difficult to support and require pretty much a panel driver for each > > panel produced. Most of them are pretty simple, and require an opaque > > initialization sequence that is usually poorly documented. > > > > This creates a tension between OEMs and distros because OEMs will > > typically get a new panel to react to a sourcing issue during > > production, and thus need some swift turnaround between getting their > > new panel and it being operational in the OS. Distributions on the other > > hand can take years to ship a kernel with that new panel driver. > > > > To solve this, I followed the example of HID-BPF and wrote a panel > > driver that will rely on BPF programs to perform the panel > > initialization. That way, we can ship the programs separately from the > > kernel, and with a different lifecycle. > > """ > > > > You can disagree with the solution, that's fair, we can also discuss on > > how to solve this problem, but I'd appreciate it if you weren't claiming > > it's all useless. > > I did read the cover-letter and I got the arguments from Benjamin, and > while in theory it could indeed solve the issue described, in reality > it won't for the reasons I exposed. > > And since it's basically allowing to accept out-of-tree downstream > driver instead of upstreaming, I'm kind against TBH. > > But I'm open to discussion, and I'll talk about display Panel in > XDC today, Plumbers and ELC next week so I hope we'll find time to > discuss about this in person! >
Hi Neil, Maxime, Benjamin, and others, I've been following the patch set over the past couple of days, mostly out of curiosity. You folks understand the details of your subsystem best, therefore I trust you with that, but I've seen a lot of misunderstandings which feed into unjustified worries about how some of this will work. For clarity, as several people have already pointed out: 1) BPF programs ship with complete bytecode and line information from the source, so I don't think the concern about the program being a binary blob is justified in any sense. The verifier has to verify it after all, before it gets loaded into the kernel. They also must be licensed as GPL to have access to any kernel functionality. 2) Adding BPF interfaces does not lock the kernel side ABI into a perpetual stability contract. There have been several thriving communities (sched_ext, HID-BPF) which have used BPF successfully in practice and have never had to make suboptimal technical choices because they support BPF-based customization. The interfaces have changed and in some cases completely rewritten without breaking users. Of course, you might decide to be less or more graceful w.r.t. backwards compatibility, but this is a choice left in the hands of subsystem maintainers. 3) On top of all this, there are several mechanisms in BPF programs to detect availability of APIs and adapt it during load to allow programs to work across kernel versions, both for functions the program can call and data it can access. As far as people being able to carry downstream changes, I think, at this point, that is already trivial with or without BPF (esp. with LLMs), the only thing you change is how easy it is for users to avoid being tied to kernel release cycles. With the right incentives people will end up sharing their BPF programs with the rest of the community. sched_ext and HID-BPF are two strong examples of this. All programs get developed in the open with community involvement, even when several companies make use of them internally for their production use cases. The theoretical worries are fine, but as far as practical evidence goes it has worked out positively for everyone involved (not once, but twice). The only valid concern I saw was the dependency on user space to load these programs. We have had a bpf_preload mechanism in the tree since forever, it has not found much traction since existing use cases didn't often need the ability to load programs early. We'd be happy to explore how it could be adjusted, or reworked to better support whatever requirements emerge from this work. In any case, I am not equipped to decide what is best for your subsystem, but at least from the BPF side, I saw several misconceptions which I hope the above can address. Thanks > Neil > > > > > Maxime > >
