On Wed, Jul 27, 2016 at 11:59:10AM +0200, Stefan Christ wrote:
> Hi Daniel,
>
> I finally found some time to look into this issue again.
>
> On Fri, Jul 15, 2016 at 09:19:22AM +0200, Daniel Vetter wrote:
> > <snippet>
> >
> > To roll new vfuncs out consistently I think it'd be great to create a
> > DRM_FB_HELPER_DEFAULT_OPS #define which sets all the fb_ops. Drivers can
> > then overwrite just what they need, e.g.
> >
> > static struct fb_ops drm_fbdev_cma_ops = {
> > .owner = THIS_MODULE,
> > DRM_FB_HELPER_DEFAULT_OPS,
> > .fb_mmap = drm_fb_cma_mmap,
> > };
> >
> > Maybe even include the .owner = THIS_MODULE line in the macro, but that
> > might be too much magic and mislead people into reusing it when it's not
> > the same module.
> >
> > Of course this would be an additional (subsystem-wide) prep patch before
> > this one here.
> > -Daniel
>
> Ok. This pattern seems like single inheritance in object-oriented programming
> languages ;-) The define looks very reasonable since these drm helper functions
> are used in lot of drivers.
>
> I would also not include '.owner = THIS_MODULE' in the define, because it would
> contain even more magic.
Agreed, that's why I left it out in the example.
> What is the preferred way for subsystem-wide patches? One big patch, one patch
> per driver or group of drivers per patch?
Since this patch is not a flag day I'd say 1 patch to create the #define,
1 patch per driver (with maintainers/mailing lists per
scripts/get_maintainers.pl on cc) for each driver. It's a bit busy work,
but easiest to do that way. For flag-day changes you kinda have to do 1
huge patch, but that easily runs into cc limits of various mailing lists.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
