Hi Ricardo, On Thu, Sep 08, 2022 at 09:11:11AM +0200, Ricardo Ribalda wrote: > > - Still on slide 16, V4L2 as an API is usable without disclosing vendor > > IP. What is not possible is upstreaming a driver. I don't see this as > > significantly different between V4L2 and the new API proposal. I > > expect this to be discussed on Monday. > > I am only considering upstream drivers. There is not much to discuss > for downstream or closed drivers :) Are we really discussing upstream *drivers*? If anything, it looks like the Kcam proposal moves most of the drivers out of upstream. > > - Slide 31 mentions that entities can send operations internally and > > listen to each other events. I'd like to better understand how that > > will work without any abstraction in the API (as that is one of the > > main design decision behind this new API) when those entities are from > > different vendors, and handled by different drivers that are developed > > independently (for instance, the camera sensor and the CSI-2 receiver, > > or even the CSI-2 receiver and the ISP). > > It is still under work. > > Hardware, specially for standard buses, should be resilient (not > crash) to format mismatches. Otherwise a mal-functionling sensor or > too much noise could crash the system (with or without kcam). > > Drivers developed together should know about the rest of the system, > so that is not the issue here. > > For drivers developed by different vendors for a standard bus, on > hardware that is not resilient (that was a mouthful), then we need to > prepare a set of read-only standard registers. I'm not even sure that read-only registers would be enough. I've experienced first-hand DMA controllers that, when the camera has its timings completely off, end up completely confused and write way outside of its assigned buffer creating big chunks of corrupted memory in the system. And that was by writing fairly legit values to registers that were meant for that, so we wouldn't be able to defend against it even with the smartest whitelist. And we were in a "good faith" situation. Giving an attacker basically programmable access to DMA engines that might not be sitting behind an IOMMU seems like a very dangerous idea to me. > > - Does the bike on slide 32 illustrate the difficult discussions we've > > had in the past and how progress was hindered ? :-) > > This is how we do code review at Google when two developers do not > want to work together. We take the bike to the rooftop and the two > developers that disagree tries to push the other developer to the edge > of the building. > > The first second, when you see your colleague falling you think that > you have won.... then you realise that you are falling with them. So the optimal solution would be that both stop pushing, or push the other just as hard without bulging? That doesn't seem like a good way to end up with a compromise ;) Maxime
Attachment:
signature.asc
Description: PGP signature
