On Wed, 08 Sep 2021, Dave Airlie <airlied@xxxxxxxxx> wrote: > This is orthogonal to my display ptr refactoring and should probably > be applied first. Yeah, overall nice cleanups, and a much easier bandwagon to jump onto than the other one. ;) Nothing too bad, a few bugs had crept in, and I had some nitpicks. > The display funcs vtable was a bit of mess, lots of intermixing of > internal display functionality and interfaces to watermarks/irqs. > > It's also considered not great security practice to leave writeable > function pointers around for exploits to get into. On the one hand I get this, but on the other hand the pointers to the structs do remain writable. I suppose it increases the complexity of an exploit by some margin? In any case, I think this is cleaner in general, and that's enough merit for the change, regardless of the security aspect. BR, Jani. > > This series attempts to address both problems, first there are a > few cleanups, then it splits the function table into multiple pieces. > Some of the splits might be bikesheds but I think we should apply first > and merge things later if there is good reason. > > The second half converts all the vtables to static const structs, > I've used macros in some of them to make it less messy, the cdclk > one is probably the worst one. > > Dave. > > -- Jani Nikula, Intel Open Source Graphics Center